Monday, January 13, 2014

Windows XP Security Essentials Cancelled

Besides running a lot of last-generation PCs (estimated at one third of the global installed base), Windows XP is an important platform for SCADA and other infrastructure integrated systems. Migrating or upgrading those components is likely to be expensive, and many owners of such systems have not planned for a replacement or upgrade path.

Microsoft announced that Windows XP Security Essentials will also not be available after XP is declared "unsupported" in April.

If Security Essentials is no longer available, other vendors are likely to also drop support for XP product lines. This may include vendors like anti-virus and other security software vendors.

If XP systems can be upgraded, they should be upgraded immediately. Systems that cannot be upgraded need to be protected by air gaps and firewall rules. Services on these systems should be limited to only those functions that cannot be migrated.

Even with these measures, there will be a lot of insecure, poorly managed systems in the global IT environment. Black hats are rubbing their hands in anticipation of the feast.

Thursday, January 9, 2014

The Promise and Peril of Self-Driving Cars

The research by Google and others into self-driving cars has been intriguing. The vast majority of traffic accidents are the fault of drivers, and being able to eliminate human error would be a huge win for traffic safety.

But if computers are driving cars, we have to take a serious look at information security in the context of a self-driving automobile. Unfortunately, most current automation does not have adequate safeguards to protect from malicious inputs.

In particular, components do not do checking or validation to make sure that commands are being issued from an appropriate source. Security researchers have demonstrated that they are able to issue commands to a Prius to control steering, braking, acceleration, and dashboard displays. They were also able to disable an Escape's brakes at slow speed.

Ford and Toyota both point out that the researchers were connecting directly to the car's CAN (Controller Area Network), which limits the impact of some of their demonstrations. But keep in mind that wireless controllers on on-board systems such as Bluetooth controllers on sound systems and telematics units on satellite roadside assistance services may provide an entry point into the automobile. Anywhere a wireless connection allows access to a component connected to a CAN is a possible entry point for malicious code.

The sorts of security measures we use for other network-connected items would still work inside a car. Provide air gaps between components that don't need to be connected. And provide for validation and authentication of commands from components that do need to be connected.

I remember discussions about PC security in the early days of the Internet, when most computer viruses were still spread by injudicious insertion of floppy disks. Way back when, we were told that PCs didn't need to have security programmed in from the ground up. I'm hoping we learn from the history of those poor decisions. A Blue Screen of Death is one thing, but a traffic fatality is another.

Thursday, June 20, 2013

The Risk from Insiders

There has been a lot of coverage of the role of a system administrator in the recent release of information about the National Security Administration's intelligence gathering methods. Regardless what you think about the methods that were revealed, information security professionals need to take a hard look at the sorts of exposures that exist due to organizational insiders.

Snowden's position as a system administrator is just the most recent high-profile insider who betrayed his employer's trust. His removal of documents on a thumb drive was viewed as unsuspicious precisely because of his job function.

As long as we have an IT infrastructure, the people who manage it will be in a privileged position. IT professionals recognize the risk; four of five professionals in a recent survey list insiders as the greatest source of risk to the environment.

The same methods that are used elsewhere in the security landscape will help to control and mitigate the risk from insiders. At a high level, there are three steps that need to be taken:

  1. Data Classification: Identify the types of data in your environment, and what the confidentiality, integrity and availability requirements are for each type of data. NIST 800-60 can provide some guidance here.
  2. Establish Control Standards: For the different types of data, we need to describe the measures that are taken to protect the data.
  3. Audit: The controls need to be evaluated for effectiveness, and the organization's compliance with the the controls must be verified on a regular basis.

Controls

There are several publicly available documents outlining control best practices and standards. Here are a few:

Some common controls include:

  • Physical access controls: Things like security guards, mantraps, proximity card systems, and combination locks on doors control physical access to sensitive areas and systems.
  • Logical access controls: In general, people should only have the level of access required for their jobs. Access controls should be as granular as possible, and high-level access should require extra levels of approval and scrutiny. Two-factor authentication should be in place for access to sensitive facilities.
  • Personnel management: Some common measures include criminal background checks, periodic security awareness training, contractual attestations, and organizational communications.
  • Separation of duties: Where possible, access should be limited to particular functions, and functions should be defined to limit access to sensitive data. In general, developers should not have access to production, system administrators don't need database access, application administrators don't need system-level access, and only the people who manage the hardware and network need physical access to the systems.
  • Network security: The network should be segmented appropriately, and firewall rules should be in place to restrict traffic between different security zones.
  • Workstations and laptops: Hard drives should have robust encryption and strong password policies should be in place. The types of data that are permitted for local storage should be established and monitored. The ability of end users to install applications needs to be restricted. Patches, anti-virus updates, and security workarounds need to be applied regularly.
  • Backups and continuity: Data needs to be protected by a combination of archival backups, long-distance replication, and local disk mirroring/RAID-ing.
  • Logging and auditing: Logs need to be collected to measure the effectiveness of these controls, and the logs need to be reviewed on a regular basis.

Some controls should get particular attention as directly addressing the issue of insider-led breaches.

It is bad enough that the security training level of such government employees is not monitored by the DHS. (Most parts of the private sector also don't track administrator security training, for that matter). Beyond carelessness or incompetence, employers need to consider the direct risks posed by their most trusted employees.

Wednesday, June 19, 2013

Medical Devices Insecure

A recent ICS Cert alert and FDA Safety communication have highlighted the lax cybersecurity that is frequently used with medical devices.

For a long time, medical devices were protected by an "air gap" which provided protection as long as the devices were physically separated from the data network. But increasing cost pressures and integration of these devices' capabilities have meant that insecure devices are being exposed to the network.

Common vulnerabilities include things like hard-coded, well-known passwords and even passwordless logins, vulnerability to SQL injection attacks, and a general inattention to security patches and secure configuration guidelines.

Security practices in the medical device industry have lagged most other IT installations. Affected devices include several where a malicious intruder (or buggy malware) could cause patient injury or death.

Wednesday, June 12, 2013

The Price of Insecurity

A recent article on the SANS web site investigated the costs associated with a security breach at Idaho State University.

John Pescatore reports that a breach at ISU's Pocatello Family Medicine Clinic is likely to cost the university $1 million over a 2-year period.

By comparison, implementing best practices in the infrastructure is likely to have defeated the attack, and would have cost around $75k. Even an aggressive security posture is estimated by Pescatore to have cost about $500k total.

Many organizations look at the costs of security breaches, but few consider the TCO related to avoiding a major breach.

Tuesday, June 11, 2013

Confirmed Report of Cyberwar Target List

A recent leak provided additional information about the Cyberwar target list maintained by the US government.

The existence of the list had previously been revealed by the administration. They released a high level fact sheet about the policy directive.

Given recent conflict between China and the US over cyber-spying, the release of this information could reduce the moral authority of the US to protest against Chinese attacks.

Sophisticated Android Exploit Spreads

Kaspersky Labs recently reported that it had analyzed a very sophisticated attack against Android devices. Backdoor.AndroidOS.Obad.a, or "Obad" for short, exploits unpublished exploits to install itself, remain undetected, and allow remote attackers to send commands to the device via SMS.

Besides installing itself and allowing remote attackers full access to the device, Obad downloads additional malware to the target device, runs up phone charges by sending SMS messages to premium-rate services, and spreads malicious files to other devices via Wi-Fi or Bluetooth connections.

It appears that the app can only infect devices which have been configured to allow apps to install from third-party sources.

Dan Goodin reports that Google has updated functionality to detect the malware and provide a warning to users when it is downloaded from an app source or browser.

Some security experts have warned of the danger posed by attackers who compromise a trusted developer's credentials and use them to upload malware to trusted download sites.

Fortunately, the attack does not appear to be widespread yet, based on analysis by Kaspersky.