Friday, February 5, 2016

Why you need to read the Summary of NIST SP 800-53 Revision 4

This is the most concise list of answers I've seen to the most commonly asked questions and misconceptions my customers, peers, and students have about NIST SP800-53r4.

http://csrc.nist.gov/publications/nistpubs/800-53-rev4/sp800-53r4_summary.pdf

Just read the table of contents for a readout on those topics... It will look as if someone is reading my email! Nice work Kelly, Greg, and Doug.

Summary of NIST SP 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations
Kelley Dempsey
Computer Security Division Information Technology Laboratory
Greg Witte
Doug Rike G2, Inc. Annapolis Junction, MD
February 19, 2014
Table of Contents

1 Introduction
2 NIST SP 800-53 Revision 4 and the Risk Management Framework (RMF)
3 Control Baselines and Tailoring
4 Documenting the Control Selection Process
5 Assurance
6 Security Controls
7 International Information Security Standards
8 Overlays
9 Privacy

Here's how I loosely explain it.
  • [Introduction] 800-53 was put in place to define controls for federal systems. Controls keep bad things from happening.
  • [RMF] This assumes the use of the Risk Management Framework. You cannot get away from this. Learn and use it. Repeatedly.
  • [Baselines and Tailoring] The baselines are not meant to be blindly applied. They must be tailored for your situation.
  • [Documentation] Document everything.
  • [Assurance] Systems assurance helps you sleep at night.
  • [Controls] Security controls enable you to protect your systems from bad stuff.
  • [International] Yes!! There is a tremendous amount of overlap between these recommendations and international ISO-IEC recommendations. Look at how they line up! Perfectly? No. But wave your hands and explain it away. Don't do that... that's a joke. Seriously. Don't do that.
  • [Overlays] NIST understands they don't cover every situation and expect you to document additional protections they don't cover. Call these overlays.
  • [Privacy] Here's an example overlay.
On my wish list is a NIST for Dummies explained using Legos...

Wednesday, February 3, 2016

DRAFT Automation Support for Security Control Assessments

Here is a draft release that came out tonight for public review. This is solid. Well-thought out. Really looking forward to where this goes, and I'm going to be following this closely.

\\

**NIST IR 8011: DRAFT Automation Support for Security Control Assessments**
http://csrc.nist.gov/publications/drafts/nistir-8011/nistir_8011_ipd-draft_vol1_overview.pdf

[From Executive Summary]
Evolving threats create a challenge for organizations that design, implement, and operate complex information systems containing many moving parts. The ability to assess all implemented information security controls as frequently as needed using manual procedural methods has become impractical and unrealistic for most organizations due to the sheer size, complexity, and scope of their information technology footprint. Additionally, the rapid deployment of new technologies such as mobile, cloud, and social media brings with it new risks that make ongoing manual procedural assessments of all controls impossible for the vast majority of organizations. Today there is broad agreement in the information security community that once an information system is in production, automation of security control assessments1 is needed to support and facilitate near real-time information security continuous monitoring (ISCM).

[From Introduction]
Automated assessments have the potential to provide more timely data about security control defects (i.e., the absence or failure of a control), better enabling organizations to respond before vulnerabilities are exploited. Additionally, automated security control assessment has the potential to be less expensive and less human resource-intensive than manual procedural testing. Any realized savings could free up resources to be used on other activities, for example, investing in additional safeguards or countermeasures or responding to security defects and incidents in a more timely manner.

[Planned Volumes]
Volume 1 Automation Support for Security Control Assessments
Volume 2 Hardware Asset Management (HWAM)
Volume 3 Software Asset Management (SWAM)
Volume 4 Configuration Settings Management
Volume 5 Vulnerability Management
Volume 6 Boundary Management (Physical, Filters, and Other Boundaries)
Volume 7 Trust Management
Volume 8 Security-Related Behavior Management
Volume 9 Credentials and Authentication Management
Volume 10 Privilege and Account Management
Volume 11 Event (Incident and Contingency) Preparation Management
Volume 12 Anomalous Event Detection Management
Volume 13 Anomalous Event Response and Recovery Management

Tuesday, February 2, 2016

SP 800-53A Revision 4 controls, objectives, CNSS 1253 Excel Spreadsheet

Here's a cleaned up and combined Excel spreadsheet version of Special Publication 800-53A r4 containing controls, objectives, and CNSS 1253 parameter values.

https://sites.google.com/site/cloudauditcontrols/

There are 3 spreadsheet tabs. The 1st one is organized by control enhancements, and the 2nd one is organized by controls. As a bonus, there is a simple search sheet in there. You can delete the table contents and paste any table contents and it will still work. Simply change the terms to search your spreadsheet.

XML download at NVD contains 2 parts, one labeled controls, and the other one is objectives: https://web.nvd.nist.gov/view/800-53/home. The spreadsheet available under downloads contains the information from both.

The original document can of course be found here: http://csrc.nist.gov/publications/PubsSPs.html.

PCI DSSv3.1 Controls, Guidance, Testing Procedures – Excel Spreadsheet

Go to the documents tab and you can download the spreadsheet containing the PCI DSS version 3.1 control requirements, guidance, and testing procedures.

Includes Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers and the new PCI DSS v3.1 Designated Entities Supplemental Validation.
https://sites.google.com/site/cloudauditcontrols/

There are now 3 different tabs. The 1st tab is organized by the requirements as you see them inside of the Data Security Standard. The 2nd tab is organized by testing procedures. The 3rd tab can be used for searching. You can sort largest-smallest any of the columns to see which controls have the highest hit rate. You can then reorganize by primary key (PK). Enjoy! :-)

Sunday, January 24, 2016

Quick Fly-by of Access Control Mechanisms (Models)

Reviewing NIST Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, and created a quick illustration to show the differences between Mandatory Access Controls (MAC), Discretionary Access Controls (DAC), and Attribute-based Access Controls (ABAC). This is what I will use in class this week to help others navigate the differences. Enjoy!

Thursday, January 14, 2016

Cloud Infrastructure Auditing Essentials

This was a draft post from some time ago. Interesting how little has changed.

Security models, business alignment, capacity planning, and performance management are more important than ever before in virtual environments. Smaller environments may have a few virtually hosted servers running on a single powerful physical server, whereas larger environments support hundreds or thousands of virtually hosted servers and desktops running on a complex infrastructure of clustered servers connected to a massive Storage Area Network (SAN).

The scale may change the scope or approach to the audit, but the same business requirements and controls exist. Resource management and monitoring of each of the components separately and collectively enable the virtual environment to function. The hypervisor has control requirements similar to those found in a server, but it also has unique requirements to ensure that the hosted environment doesn't present additional control weaknesses to the guest operating systems. The guest operating systems have unique control requirements because of the necessity to keep appropriate segregation controls in place between servers processes, and to control its unique attack surface. Somewhat complicating this mix are different conceptual approaches to creating the virtual environment.

Great! I think. Where do I start? Now I have a cloud audit!

Start with scope. Identify exactly what you want to be part of the audit. Where does the data exist? What are the boundaries? Where's the management tools for that infrastructure? What systems access that scoped boundary?

Remember the basics. They don't change. They haven't changed for decades. Identity provisioning and deprovisioning, authentication mechanism and protocols, authorization grant/scope/enforcement, data protection, malware protection, malicious use detection/prevention, log management, change controls, backups, etc. Applies to nearly every single system directly or indirectly as an entity level control. Don't forget additional administrative controls, policies, documented procedures. Remember physical security and additional entity level controls. Finally, think about data and system lifecycle…

But this is a… [firewall/storage system/hypervisor/… etc.]. Excellent! Now let's look at the additional configurations and controls that are unique for each technology.

Documentation is everything. There's an art to documenting audit output and artifacts. What's the use case? Who will use the information? Internal use? External customer review? For example, how much information must be documented and to what level such that the purpose of an external review is satisfied while still protecting internal trade secrets? Maybe we don't trust the external party, or the security infrastructure of the external party to keep the data we provide to them confidential. Certainly understand that there are many times where we don't have a choice in this discussion – and I've been there many times – but if you have a choice in the matter then you should execute that choice. Not everyone agrees with me on this. This is my own opinion. I'm a fan of transparency, but not transparently providing potential attackers information that can be used to harm my infrastructure.

Help with the cloud! Okay, this is more complex because some of the technologies and architectures change the game. However, from a control objective perspective, that still hasn't changed. The objective is the same. Now, whether you own the technology or execution may have changed, and that's where you need to look into what visibility you have into your provider's enforcement of the controls. You have a certain risk profile/risk threshold and you have to make the call based on the situation whether you are comfortable with what contractual obligations they have to [1] enforce specific control objectives, [2] have them reviewed by an independent third-party, and [3] report the results to you.