Tuesday, February 10, 2015

Discussion of SCADA and Multitenant Environments

Here's a reminder that a technical control failure can be driven by management/administrative and/or governance failures. Recently, a conversation focused on multitenant environments handling very different data types and sensitivities.

I would not put SCADA/PLC power distribution control systems on the same physical frame as consumer payment processing or anything else externally accessible. It's not simply a matter of whether the system can be secured. It's a matter of who is ultimately responsible for the security of the system. The security of the system is going to be hard enough. If there is confusion as to who is responsible for system security, then you significantly increase the likelihood of control failures from system drift over time.

Thursday, January 22, 2015

"We've got you covered!" Be careful. Be very very careful.

Very interesting day today listening to a vendor discuss how they have security covered. To hear them speak, you would think that they have covered security from soup to nuts. In ways that you can only fathom imaginable.

Read the fine print.

Better yet. Read your authoritative sources, risk management process findings, and understand your own requirements.

Three years ago I enrolled my little boys in MMA classes. They enjoyed it so much that I very soon got them started in private lessons with a professional UFC fighter. What I found to be fascinating was that despite his repertoire of tricks and experience, he often went back to the basics of what was necessary to succeed in a fight. Sure, the extra stuff can take you over the top. But if you don't understand the fundamentals, you're setting yourself up for failure.

Security is the same way. You can look at all of the new bells and whistles on the market, but if you can't execute on the fundamentals, you're setting yourself up for failure.

Perhaps one of the more interesting moments I've had in this industry came when a friend simply said to me, "Chris, this doesn't have to be that difficult. As long as you can control access to the data, you win. Every time."

On the surface of it, this is true. However, executing this idea is more than just access controls. He knew this, and that led into the discussion of the different vectors which were either a path, or gateway component, for access to the data and exfiltration of the data. The network is a critical piece of this architecture, and absolutely must be secured with appropriate access controls, intrusion prevention, network behavior anomaly detection, etc., etc..

Other things to consider include endpoint protection, log collection, log analytics, data loss prevention, and other controls that identify a potential compromise in the secure state of your system security. Don't lose sight of the big picture. Keep in mind the comprehensive set of controls necessary to protect access to data, inclusive of context. Subject. Data object. Paths. Demarcation points.

Remember technology affects every part of the infrastructure. At its best, security is a competitive differentiator. At its worst, security is your competitors differentiator.

Wednesday, December 17, 2014

Significant Update to SP 800-53a – Building Effective Assessment Plans

Released 12/11/14…
SP 800-53a is the sister document to SP 800-53.
 
NIST Special Publication 800-53 Revision 4
This document is the body of controls.
NIST Special Publication 800-53A Revision 4
This document provides guidance on how to assess – test for compliance – each control outlined in the body of controls.

Sunday, October 5, 2014

BAD USB Opportunities and GOOD USB Drives

The first thought that immediately came to mind wasn't so much just counterfeit or cheaply made USB devices, but also USB chargers. We plug our android, blackberry, and iPhones into inexpensive chargers bought off Amazon.… Makes me wonder if it's really a good deal. Or just an incredibly wonderful opportunity for a nationstate that manufactures those devices and already understands this and many other exploits capable of going unnoticed.

Reading articles such as this well-written bit by , thinking about Cottonmouth, and considering the pervasiveness of potential compromised devices.... you can understand the effectiveness of this attack vector. Then consider the likely reuse of these compromised devices. They are going to be around for a long, long time.

GitHub Link: https://github.com/adamcaudill/Psychson

By the way, trusted USB devices… Excellent opportunistic marketing for a device that was ahead of its time... Smart company.

IronKey USB Drives
  • http://www.ironkey.com/en-US/solutions/protect-against-badusb.html
  • IronKey Enterprise 250 flash drives are FIPS 140-2 Level 3 validated with AES 256-bit hardware encryption.
  • Enforce device-specific policies and mitigate risks of data loss by remotely disabling lost or stolen drives.
  • A ruggedized, waterproof metal chassis resists physical break-ins and is tamper-proof.
If you work on a security or audit team – take advantage of the perks that come along with the position and apply for a free evaluation: http://resources.imation.com/ikenterprise-evaluation.

Thursday, September 25, 2014

What's in a Name? Shell Shocked. Deserves a 10.

This one deserves a 10. This is in regards to http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271.

Original release date: 09/24/2014
Last revised: 09/24/2014
Source: US-CERT/NIST

Overview

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Impact

CVSS Severity (version 2.0):
CVSS v2 Base Score: 10.0 (HIGH) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend)
Impact Subscore: 10.0
Exploitability Subscore: 10.0

 

Tuesday, September 23, 2014

MAC vs DAC vs RBAC

Recently had a discussion regarding mandatory access controls, discretionary access controls, and role-based access controls. The goal of the discussion was to discuss and understand use cases in the context of risk – which is driven by the business impact of a loss in the confidentiality, integrity, or availability of data.

Take for example an environment that does not handle sensitive data whereby a loss in confidentiality would have significant and sustainable impact. However, there are situations in which the delivery of the processed data is mission-critical for the company to continue operations. Therefore, a violation of the integrity of the data or availability of the data would have significant impact.

Discretionary Access Controls (DAC) and Mandatory Access Controls (MAC) describe the permissions required to access an object in relation to other objects. Role Based Access Controls (RBAC) simply describes the grouping of identities and application of permissions to those groups. The Reference Monitor (RM) concept and requirements still apply when building the environment, such as situational context, forensic auditing, and visibility into permissions.

DAC suggests someone can give you access to an environment, and you have free reign within that environment without knowledge of any particular object sensitivity. Your permissions are governed by your identity.

MAC suggests that in addition to permissions associated with your identity, every object inside the environment has its own label associated with the object. Now, based upon permissions granted to me, perhaps associated with my role or group, I can only perform actions on tagged objects if an explicit policy grants me access to the object. Conversely, a policy can be written based upon tags/labels to explicitly deny me (or my role/group).