Risks of Automatic Image Downloads in Gmail

This morning, as I logged into my Gmail account, I was notified that the company had decided to turn on automatic image loading for all email.  This made me wonder, isn’t this going to be a security issue?  Images contained within email are generally not embedded, but need to redirect to a specified URL located on a remote server.  Malicious users can obtain information about when you loaded an image and that the email you accessed the image from is legitimate and active, potentially spamming, phishing or attacking you with malware in subsequent email messages.  You can also give up your IP address, which can provide attackers with a close estimation of where you are located.  Any information they find regarding your whereabouts or Internet activity can be used to specially craft messages and URLs to obtain personal information or destroy your data.

So, how does Google plan to mitigate these risks for its customers?  Well, Google says that their proxy servers will host all images, preventing attackers from knowing where the email was opened from or exploiting any security vulnerabilities on the local machine due to embedded malware.  This proxy solution does not, however, prevent attackers from learning your location or whether your email address is active.  Loading images automatically also starts something called ‘read tracking’, whereby senders can tell whenever a message is read by a specific recipient.  

Loading images within the proxy servers will speed up the time it takes users to open Gmail messages, and Google could cache all email images before a recipient opens the message to prevent tracking.  If Google does cache all messages, attackers could implement a denial of service attack on the company by sending millions of images to their proxy servers.  

Luckily, for those concerned with this new setting, Google has allowed users to revert back to the previous configuration whereby each user needs to load the individual email messages manually.  From a security perspective, this is a much safer option.  We already receive enough spam and phishing attempts, and each suspicious email should be scrutinized for its authenticity – we do not need to now worry about strangers figuring out that our accounts are real and where we are located! Turn off the automatic image download option if only to protect your own privacy. 

Secure Control System Network Design

When designing control system networks in a secure fashion, it is important to note the different requirements that exist between various business networks.  Control systems vary widely from corporate network resources in need for speed, reliability and uptime.  Control systems rely on real-time operations and therefore must remain highly reliable.  Business networks, on the other hand, operate over low-cost Ethernet to provide fast access to resources using TCP/IP.  SCADA systems operate between these two networks to relay information from one to the other and need specific components from each network to function.  SCADA systems must be able to operate in real-time while using TCP/IP to communicate data to the business.  

These obvious demarcation points on the network are great spots to segregate networks when developing a secure control system network design.  The SCADA system should sit on a DMZ, a security zone located between the business and control system networks.  It is not ideal to place business applications on the same network as the control systems because legacy systems within control are vulnerable to malware and malicious traffic, while operating across insecure protocols, such as Modbus.  A firewall placed on either side of the DMZ protects the control system and the business network from vulnerabilities and threats found within each.  Placement of intrusion prevention systems and other perimeter security devices between the SCADA network and each other network is best practice.  

Systems within the control system network include RTUs, PLCs, and HMI systems.  The SCADA network will also host HMI systems plus data historians, MTUs, and ICCP clients.  The network containing business applications will include popular business software programs, as well as supervisory workstations for monitoring SCADA systems. 

Placement of the control system network devices in the most secure zone, or deepest layer, is another best practice.  Traffic should flow from the higher security zone to lower zones, but not in the other direction.  Information within the control system network should be enabled through the firewall to the DMZ as needed, and the SCADA DMZ equipment should communicate through the firewall out to the business networks.  Traffic should not traverse the firewalls directly from the control networks to the business LANs.  The DMZ acts as intermediary communication center, taking in information to its systems from the control network and passing information along to the business network.  This same design must be used for any traffic that needs to reach control from the business networks.  

Set up file shares and patch management servers within the DMZ to capture information from one network before passing the authorized information along to the receiving network.  This will prevent malicious code from traversing directly to a targeted host because, theoretically, a different port and IP address should be used from the DMZ host to pass traffic.  The important considerations when designing security into control system networks is to segregate the vulnerable control network as much as possible from the highly volatile business LAN.  The DMZ acts as a buffer to double check that traffic is traveling to approved resources, and infection in the DMZ is less intrusion and detrimental than an attack of the control system resources themselves.