This blog is about understanding, auditing, and addressing risk in cloud environments. Systems and architectures are rapidly converging, hiding complexity with additional layers of abstraction. Simplicity is great for operations - as long as risks are understood and addressed.

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.

Tuesday, September 23, 2014

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).

Thursday, September 4, 2014

This was some quick research simply to prove a point. Security is important to your customers. If it's not, then it should be.

Highlight of a recent conversation with a Fortune 500 company who called me while I was at DEFCON. Network team, firewall team, and others were on the call. They have special awards for companies like this.

Customer: I need ports, protocols for the administrative
network.

Me: Excellent. Not a problem. Can you explain the use
case?

Customer: It's for DMZ access.

Me: Are you going to expose the management network to
the DMZ?

Customer: Yes.

Me: On the face of it this seems like a really bad
idea. This is a massive compute platform. Can you explain what kind of
segmentation you have inside the DMZ?

Customer: I have no idea what kind of segmentation we
have inside the DMZ.

Me: At this point I could do one of two things. I can
either give you the information you want and trust that you have a
security team that will look into this, or I can recommend you take a step
back and understand what you are trying to accomplish – including the potential
risk implications.

Customer:… Silence… Maybe we should
set up a meeting…

Okay – onto the quiz.

Question: What do these companies have in common?

The Home Depot

JP Morgan Chase

UPS

REI

CVS/Caremark

Rite Aid Pharmacy

Northern Trust Company

Wall Street Journal

Bank of America

Apple

Goodwill

CNET

Boeing

Lockheed Martin

Goldman Sachs

PF Chang's

AT&T

Walgreens

And 100+ more that were fortunate to find something special.

What happened?
Over what time period?

Hint…Quote from Olaf...
“Oh, I don’t know why, but I always loved the idea of summer, and sun, and all things hot.”

Wednesday, September 3, 2014

Yes, I understand the importance of Requirement 7. Restrict access to cardholder data by business need to know.

Increasingly, my respect grows for peers that communicate in plain English. Why? Because I understand how well you must understand material to [1] discuss it vs. [2] discuss it plainly.

Several years ago I was listening to a public radio tribute for a great Nobel prize-winning physicist. He had recently passed away, and his mark on society wasn't just his great research. It was his ability to plainly explain complex concepts in a way that people understood, and in a way that excited people. Creative passion. Made people want to understand and know even more. He made physics accessible to the average person.

Like many of you, I'm asked to understand a wide variety of topics. That means that I'm often coming back to topics that I've worked with before, and noticing new things.

As an example, requirement 1.1.5 is nicely done:

Requirement 1.1.5

Description of groups, roles, and responsibilities for management of network components

Testing Procedure

1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components.

1.1.5.b Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented.

Guidance

This description of roles and assignment of responsibilities ensures that personnel are aware of who is responsible for the security of all network components, and that those assigned to manage components are aware of their responsibilities. If roles and responsibilities are not formally assigned, devices could be left unmanaged.

Plain English: Validate everything is managed.… No device left behind…

Now here's an example of much-needed simplification with respect to roles. The extended original version is fine if you work with this every day. But if you don't, I believe it's incredibly important to keep it simple. I think it would be a fun exercise to see how short and direct you could make the PCI-DSS.