Measurable Security

Metrics are critical for continuous improvement, understanding where you sit in relation to where you need to be. Perhaps you've seen this before. I'm familiar with most of these projects, but this initiative in particular was new to me.

http://measurablesecurity.mitre.org/directory/areas/systemassessment.html

Nice list guys. Cross-posting here.

System Assessment

The narrative text description for this page is currently under development. Please check back later.
In the meantime, standardization efforts in this area of cyber security include the following:

• Common Vulnerabilities and Exposures (CVE)
• Common Weakness Enumeration (CWE)
• Common Weakness Scoring System (CWSS)
• Common Weakness Risk Analysis Framework (CWRAF)
• Common Configuration Enumeration (CCE)
• Common Platform Enumeration (CPE)
• Open Vulnerability and Assessment Language (OVAL)
• Malware Attribute Enumeration and Characterization (MAEC)
• Common Vulnerability Scoring System (CVSS)
• Software Identification (SWID) Tags
• U.S. Federal Desktop Core Configuration (FDCC)
• United States Government Configuration Baseline (USGCB)
• U.S. Defense Information Systems Agency’s (DISA) Security Technical Implementation Guides (STIGS)
• Center for Internet Security (CIS) Benchmarks
• Security Content Automation Protocol (SCAP)

Common Audit Regulations, Standards, Practices, and Guides

These link to the original information sources.

The Abbreviated List

• Common Regulations and Standards SOX | GLBA | FFIEC | Basel II| FCRA | HIPAA | NERC | NRC | CFAA | FISMA | FRCP | FISCAM |Privacy Act of 1974 | Safe Harbor | NYSE  | PCI-DSS | COSO 
• Audit Practices and Guides | ISO 27001:2005 | ISO/IEC 27002-2005| OGC ITIL | BCI | CobiT | ISACA | AICPA | ISACA | OECD

Cloud Security and GRC: Internal Controls

Environmentally Friendly.

Here's the flow of a security presentation I sometimes use to stimulate thought and focus around controls and how they can be orchestrated, coordinated, to deliver contextually rich information security and cloud auditing relevant views of the environment.

Environmentally Relevant. 

The enormous data set produced by monitoring and management tools delivers useless information if the data isn't comprehensive of the its environment. Several years ago I worked for a Network Access Control (NAC) company. During Proof of Concept demonstrations we often found more devices on the network than the organization thought was possible. It wasn't uncommon to discover 15-20% more than a company thought they had on the network. One particular example found - not kidding - 20,000+ devices more than their estimated 40,000 devices the company thought they had worldwide. Yes, this is extreme. But it's also those experiences that drive my belief you have to know what you have before you can secure it. 

Here is how I summarize action items during discussions around this topic.

Security and Auditing are Multidimensional. Not One. Not Two.

"Chris. Are you sure you want to move to IT Audit?"
I wasn't sure what to expect during the shift from corporate security to corporate audit. The IT Audit Manager, Mike Schiller, and IT Security Manager, Brian Wrozek, had done a phenomenal job aligning objectives and approaches. The commonality in our mission objectives and mutual respect between the two teams is part of the reason I felt so comfortable making the move.

"Mike!! Look at all the stuff I found on this one box!"
Mike wasn't impressed. "Chris. What's the objective of this system? Where is it located? What data is stored on this system? How long has it been in operation? What projects are in place that will be completed in the next couple of months that affect the controls on this system?"

My introduction to multiple dimensions... 
Mike patiently walked through every "finding" and discussed each one. When we were done, there were still issues with the system, but they were now more correctly framed in context of the business as an organic function, and not "just" a polarized point-in-time evaluation. His careful mentoring of the team built the understanding that our audits have to encompass a review of the systems, operational processes, and alignment to the business.

In a previous post, we discussed The Circle of Trust - Cloud Audit Assurance. Pulling the three cycles discussed in that post together, they overlay each other nicely to show the nice interrelationships between what you have (Assets), what you want to accomplish (Alignment), and how you are going to do it (Operations). This model is as complex or as simple as you would like. It's a question of detail. Until next time.... Here's the model again (click it for a larger image):

The Circle of Trust - Cloud Audit Assurance

Assurance is the grounds for confidence that the set of intended security controls in an information system are effective in their application. 
(NIST  SP 800-37 and SP 800-53A)  

Cloud Audit Assurance. 

What can you do to provide assurance that your cloud infrastructure serves the purpose for which it was designed while protecting the data? Where do you start? Where does trust begin? Let's discuss three cycles that may help frame the discussion and an approach that may work for you. There's truth in the effectiveness of simple models that are easily understood and that can deliver repeatable results.

Start with the Business: Solution Alignment Cycle.
A previous post discussed GRC in the context of the business. We have to understand the objectives of the business and how the infrastructure and workloads align and support the objectives, in the context of risk, while managing compliance concerns. One of the great values of GRC tools is their ability to continually monitor and measure the effectiveness of your GRC program. A governor, or speed limiter, is a device used to measure and regulate the speed of a machine, such as an engine (wikipedia..). The important analogy is the feedback mechanism to regulate the effectiveness of the mechanical engine to perform as expected. The illustration below shows a simple cycle that is intended to be self governing.

Governance (alignment to business objectives) greatly affects how Risk (probability and impact) and Compliance (authorities, contracts, policies) are managed. Frameworks (COBIT, etc) may be used to help drive the GRC program, whose effectiveness is measured using GRC Tools. The workflow of the GRC Tool helps to continuously regulate the cycle.

Manage the Technology: Solution Delivery Cycle.
The Storage, Network, Compute, and Hypervisor (infrastructure) and Solutions (work loads), deliver a service. The effectiveness of a solution (capacity, performance, alignment/ability to meet needs/applicability) continually drives the selection and amount of technology assets required to deliver the solution. Put differently, the measurement of the effectiveness of the solution drives the hardware and software requirements.

Add Secure Operations Processes.
The PCVMR cycle was discussed in the previous post using the mission of a submarine. Provision the technology assets. Configure in accordance with your authorities, best practices, and policies. Validate against your checklists and using (as risk appropriate) additional tools, scanners, or third party resources. Monitor for deviations from your baseline. Accurately Respond and improve your processes based on what you learned.

Mission Operations - PCVMR Cycle

Reminiscing About the Past

Assurance.

Leading off the previous post, let's delve deeper into the processes that helped provide mission assurance to the crew taking the boat down to operational depth. We spoke of submarines and the mature operational approach that allowed a crew barely out of high school, most with no formal education, to not only function in these demanding environments, but excel and push themselves and their equipment to the extremes. 

Why were we successful? 

It was more than top-notch training. It was more than engineering and equipment superiority. It included a deep knowledge of operational processes that work in orchestration with the equipment and a firm understanding of the mission objectives and risks. The effectiveness of everything was measured and fed back into the processes and equipment.

Provision | Configure | Validate | Monitor | Respond

The PCVMR process cycle provides insight into how we were able to attest to the assurance of our boat to keep us safe and deliver on her mission. Here's how it works.

Provision: Equip yourself with the right systems for your mission. Submarines are equipped with systems appropriate for accomplishing their mission. Ballistic missile and attack submarines have very different missions and very different equipment... and crew and training. The highly specialized Submarine NR-1 was outfitted with equipment and capabilities not found in other subs because that's what her missions required. 

Configure: We sometimes laughed at a few of the Standard Operating Procedures (SOPs), but we respected them. Some would say, "Rules are written in blood." That's because somebody paid a heavy price for that stupid rule to check that breaker or valve lineup twice. Every system had a checklist for every operational lineup. These lineups are thoroughly tested by smart engineers, and every effort is made to follow the book. It's one thing if you're throwing your leftover litter into a McDonalds wastebasket. It's another to dump or pump it overboard underwater. One is casual. The other is very carefully handled. 

Validate: Everything was checked twice before getting underway. Every critical system was reviewed. Every change. Anyone that's spent time underway will recall the repeat-backs required on the phones as you read from a procedure to senior operator. The senior operators then repeated the same requests to watch officers for final permission. Everyone backed each other up to validate actions. Important actions were verified formally by a second person and signed off by all parties involved. Some critical actions required multiple validations and checks based on the affect of the system to the ship's mission. Once everything is known, you have entered an operational steady state, or a known state of operations. 

Monitor: Despite the best intentions to engineer flawless equipment and set everything up correctly, things go wrong. Systems are heavily monitored, automatically and manually, many both, to identify state deviations, or changes in the known state of operations. These may be intentional by the crew and known. These may be intentionally malicious from an external source, or changes could exist because of an inexperienced operator. The monitoring systems (some of which are redundant) help identify the early state of changes to give operators the most time to respond appropriately. Monitoring occurs across many complex related systems, and you need to identify issues as quickly as possible to minimize their impact. 

Respond:  It is the operator's experience and well-rehearsed drills that helps lead the best response. Realistic drills are part of every day life underway in preparation for when something bad happens. You expect something bad to happen. And it does. It's the workflow, methodical analysis, and rapid response that make the difference between "that was close!" and a new SOP. Rules are written in blood. Responses to incidents are debriefed for details that could could have managed the incident better than what was done. After Action Reviews. Post Incident Reviews. The outcomes of these meetings completes the PCVMR Cycle as they affect the Provisioning, Configuring, Validating, Monitoring, and Responding. 

Can you see how this translates to cloud security and audit? We'll dig into that next. It's time to walk out of the bubble and back into the cloud:).