Tuesday, February 19, 2019

Cloud Myth: It's all the same... or It's all different...

Another round of questions....

1. What is the biggest myth business and IT departments have about the cloud?
The biggest myth organizations have about IT cloud infrastructure is that you can lift and shift your existing workloads into the cloud using the same architecture, methodology, and tools that you have used in the past. This may be true in some cases, but the reality is the architecture radically changes from one cloud to another. They all have different capabilities, and some have features that may drive business decisions from cost savings or an architectural requirement. Moving to the cloud presumes application distribution and potentially shifting trust boundaries. Risk must be managed. Visibility is required in hybrid and multi-cloud deployments along with the ability to uniformly report on and affect change across the different environments.

Planning is critical to safely and effectively migrate workloads to the cloud. The good news is that at this point there is a large body of knowledge from those that have gone before you. There are astounding successes and equally colossal failures. Work with your cloud provider closely.

2. Why is this myth so pervasive?
It's not uncommon to make assumptions based on what you have known before. However, the shift to software defined architecture creates capabilities, and in some cases limitations, that differ from traditional physical infrastructure.

3. In what way/ways does this myth hamper IT and/or business operations?
Assumptions slow the end game because you start with the wrong ideas and end up with misguided plans. A bad result is that your applications don't work as intended. Worse? The applications work, but risk is mismanaged, resulting in ineffective security or compliance controls.

Work with your cloud provider and correct your assumptions. Then create realistic strategies and a working plan. Ensure you have the proper technologies to support your applications – required to run your business – and the appropriate security and compliance controls in place – required to protect your business. Borrowing from the military, "Prior planning prevents poor performance."

4. What can be done to dispel this myth?
Learn. Attend migration workshops of the cloud providers that interest you. Preferably more than one. Build healthy budgets into the migration plans. Plan. Manage your risk.

And specifically, build budget into the plans to ensure you fully understand geographically distributed deployments and can identify risk across the distributed Data-center. The tools and methodology may change, but the end objectives of visibility and control do not change. Those are fundamental to assurance. Again. Manage your risk.

5. Is there anything else you would like to add?
Good business leaders understand and respect risk. Great business leaders learn how to manage and respond effectively to risk. The presumption is visibility. You cannot act on what you cannot see.

Thursday, February 7, 2019

Don't be Naive - Good to Great

Most people like money and opportunity. A lot. Ideally, the mission objectives and sense of purpose drive motivation, but given a similar sense of purpose and higher pay.... It happens. People move on. Getting faced with shifting slightly grey lines... Operatives working for government entities get some of the best training and are forced to learn to be resourceful. Great assets. You have to think, where do these people go in their careers? One of my closest friends is a combat mercenary. Why? Because he learned a specific skill set from the government that enables him to be effective in the physical combat theater - And he gets paid a lot of money to use this skill set. The pay? Good to Great.

Awesome reporting. Great work guys.

Wednesday, February 6, 2019

Well-Architected Cloud = Manage Your Risk. Seriously.

Manage your risk. You got cloud? What is well-architected?

Well-Architected = Risk Managed.

This series of questions came across my desk this morning. Interestingly, it took me back nearly 10 years when I first started in cloud security. I’ve been in information security for nearly 20 years, and I believe much of the strategy and definition – the construct – of the secure environment is still the same.

How would you define a well-architected cloud?

A well-architected cloud provides assurance, or the grounds for confidence that the integrity, availability, confidentiality, and accountability have been adequate met. “Adequately met” includes (1) functionality that performs correctly, (2) sufficient protection against unintentional errors by users or software, and (3) sufficient resistance to intentional penetration or by-pass. This is a close paraphrase of the definition of assurance from NIST SP 800-27. 

What are the elements that go into a well-architected cloud?

There are three elements covering the technical implementation of a well-architected cloud. The technical controls of best practices, regulations, and standards based on CIS, NIST, PCI DSS, and others can be summed up into one of three categories including configuration, solutions, and design. The situation is straightforward. The configuration of every application and endpoint must be configured to reduce the probability and impact of intentional and unintentional action. Hardening guides address many of these issues for network, compute, storage, and virtualization components. System solutions provide additional insight, accountability, or control over the security and compliance of the environment. Examples include firewalls, identity and access management, and systems monitoring. Finally, given that each one of the individual components are secured as much as possible, and additional solutions provide you the insight, accountability, and control over your environment, your last consideration is the environment design. This can include separating trusted and untrusted zones, implementing a DMZ, providing secure multi-tenancy, etc. 

What's the best way to achieve a well-architected cloud?

Identify the business objectives, dataflow, and preferred user interactions before building the system. Decide how subjects will interact with data objects and what controls will be in place across the reference monitor that controls authentication and authorization. The security model of the most trusted systems in the world depends upon strong access controls. This only works if you understand who has access to critical data and how to protect it using secure configurations, solutions, and design. Bottom line. Plan for it. The military has a saying, “Prior Planning Prevents Poor Performance.”

What should IT never do when constructing a cloud architecture?

Assume that you can do a direct lift and shift into the cloud. The intent of the controls have not changed, and neither have your objectives. However, the implementation, visibility, and tools available do change. Take the time to understand the platform you are moving your data into and how that platform functions versus how you have handled your data in the past on premises.

What are the cloud architecture pitfalls that IT might fall into?

Again. Never assume you can do a direct lift and shift into the cloud. Never embark on a journey without a known destination and plans for how to get there. Start with a comprehensive set of security requirements inclusive of configurations, solutions, and design principles that must be met. 

Is there anything else you would like to add?

Cloud environments bring tremendous opportunity, as long as you can maintain visibility and manage risk across the entire environment. That's been a consistent message on this blog since its inception in 2011. Manage Your Risk.

Thursday, March 15, 2018

Breaking up the Mundane

Blatantly ripped off some website...

1. What did the traffic light say to the car? -- Don’t look! I’m about to change.
2. Why was the little strawberry crying? -- His mom was in a jam.
3. What do you call a nosy pepper? -- JalapeƱo business.
4. Why are frogs are so happy? -- They eat whatever bugs them.
5. How do you befriend a squirrel? -- Just act like a nut.
6. Have you heard about the corduroy pillow? -- No? Really? It’s making headlines!
7. Why did the jaguar eat the tightrope walker? -- It was craving a well-balanced meal.
8. What did the big bucket say to the smaller one? -- Lookin’ a little pail there.
9. Why do chicken coups always have two doors? -- With four, they’d be chicken sedans.
10. What did one hat say to the other? -- You stay here. I’ll go on ahead.
11. Why did the lifeguard kick the elephants out of the pool? -- They kept dropping their trunks.
12. What do you call a pony with a cough? -- A little hoarse.
13. What do you do if someone thinks an onion is the only food that can make them cry? -- Throw a coconut at their face.
14. What do you call a man with no arms or legs wading in a pool? -- Bob.
15. What do cows most like to read? -- Cattle-logs.
16. How does a duck buy lipstick? -- She just puts it on her bill.
What do you call a guy with a rubber toe? -- Roberto.
18. What did the cop say to his stomach? -- Stop! I’ve got you under a vest!
19. What do you call a snowman on a hot day? -- Puddle.
20. What do you do with a sick boat? -- Take is to the doc already.
21. What did the rubber band factory worker say when he was fired? -- Oh, snap!
22. What do you do when you see a spaceman? -- Park your car, man.
23. What did one shark say to the other as he ate a clownfish? -- Well this tastes a little funny.
24. What do you do with epileptic lettuce? -- Make a seizure salad.
25. What did the older chimney say to the younger one? -- But you’re way too young to smoke!
26. Who do call when the ocean needs a little cleaning? -- A mermaid, of course.
27. What do you call a bee that’s having a bad hair day? -- Frisbee.
28. Which plant rules the garden? -- The dande-lion.
29. Why did the skeleton hit the party solo? -- He had no body to go with him.
30. What does the cobbler say when a cat wanders into his shop? -- Shoe!
31. Why was the poor guy selling yeast? -- To raise some dough.
32. What’s a firefly’s favorite game? -- Hide-and-glow-seek.
33. Who does a pharaoh talk to when he’s sad? -- His mummy, of course.
34. What do you call a pooch living in Alaska? -- A chilly dog.
35. Why was the sand wet? -- Because the sea weed.
36. How much does a pirate pay for corn? -- A buccaneer.
37. Did you hear about that wedding? -- It was in-tents.
38. How did Darth Vader know what Luke got him for Christmas? -- He could feel his presents.
39. What do baby kangaroos wear when it’s cold out? -- Jumpsuits.
40. What kind of music to chiropractors listen to? -- Mostly hip-pop.
41. What’s the most famous creature in the ocean? -- The starfish.
42. I just wrote a book on reverse psychology. -- Do not read it!
43. What do ants get when they do all their chores? -- An allow-ants.
44. Why don’t skeletons watch scary movies? -- They just don’t have the guts.
45. What did one egg say to the other? -- Eggs-cuse me, please.
46. What’s so bad about Russian dolls? -- They’re all so full of themselves.
47. Why doesn’t anyone want to shave a crazy sheep? -- Cause it’s a baaaaaaaaaad idea.
48. What do clouds wear under their shorts? -- Thunderpants.
49. What does a farmer say after feeding a stick of dynamite to his steer? -- Abominable! [A-bomb-in-a-bull}
50. Why wouldn’t the shrimp share his treasure? -- Because he was a little shellfish.

Monday, February 27, 2017

IoT & Cloud Security Best Practices

**Briefly** in response to a request over LinkedIn... :-)

Here's a couple links that may be helpful regarding IOT and cloud security best practices!

You can use the NIST guidelines here:

Here's a couple AWS resources:

Sunday, October 30, 2016

2016 Controls Map - Indexed to NIST - Free Gift

Delivered to you with pleasure and as a courtesy of one of the best managers I have had. Jerry Breaud trusted me to run with my gut instinct and allowed me to work on a personal project designed from its initial conception to give as much to the community as it does to our company.

Thank you to VMware and Intel, both of whom supported this effort and allowed me to create, validate, and openly give this information back to the community so that others can benefit from this work product.

You can find the mapping under the documents tab. Direct link here.

Look for 2016 Controls Map New_River_v5 CG (012).xlsm. Please note this is a macro-enabled spreadsheet. View the macro using [ALT]-[F11].

Quick Summary
The purpose of the build kit is to create a blueprint for a repeatable solution that is capable of meeting multiple compliance requirements. The objective is to build the solution properly the 1st time, and have the solution meet the technical control requirements for multiple regulations, standards, and best practices. While we have appreciation and understanding for administrative and physical controls, our focus is understandably on the technical configuration and setup of these complex virtual systems.

We continue to see large multinational organizations struggling with the complexity of multiple regulations and required combined control frameworks. We have spoken with senior security and compliance executives from financials, defense, and many other entities with sensitive data. This is a serious and daunting problem – and we have good news.

The opportunity is to create a sustainable common controls baseline to address multiple regulations and standards. It's as simple as this. The result helps organizations quickly to a lowest common denominator set of technical configurations that collectively create a technical build gold configuration. This is a baseline set of configurations with a target of achieving 90+ % compliance for a majority of authoritative sources out-of-the-box aligned with NIST controls.

Someone recently looked at the body of work and made the assumption we simply borrowed from existing mappings. We looked. And were not satisfied with the accuracy and usefulness of the common existing mappings out there. This was several months of heads-down effort reviewing every single control and then getting two different third party audit firms to supplement the effort.
  • Review and complete where necessary control mappings from common regulations, standards, and best practices into NIST.
  • Identify any control gaps and create an effective control overlay. 
  • Independently validate results by at least 2 different consulting companies formally, and informally with a number of peers.

The incredible work NIST has done with bodies of work like NIST SP800-160 Systems Security Engineering Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems by Dr. Ron Ross, Michael McEvilley, and Janet Carrier Oren greatly inspired our team. We borrowed generously from these materials.
  • Recommended common control alignment map to NIST with additional control overlays addressing multiple regulations and standards. 
  • Recommended product configurations, security solutions, and specific design requirements to create repeatable, compliant, secure systems.

But I didn't think PCI mapped directly into SP800-53?
It doesn't. Please allow me to introduce the concept of overlays in case you haven't run across them before. Taken from the summary document...

[...] To help ensure that selected and implemented controls are sufficient to adequately mitigate risks to organizational operations and assets, SP 800-53 Rev. 4 introduces the concept of overlays. An overlay provides a set of security controls, control enhancements, and supplemental guidance for community-wide use or to address specialized requirements, technologies, or unique missions and environments of operation. For example, the federal government may decide to establish a government-wide set of security controls and implementation guidance for public key infrastructure (PKI) systems that could be uniformly applied to information. [...]

Tuesday, October 4, 2016

Microsoft Throws Down!

First, I read this... https://techcrunch.com/2016/10/03/microsoft-expands-azure-datacenters-to-france-looks-to-beat-aws-on-image-of-trust/. Then I reviewed the Trust Center *once again*... to see if there have been any changes in the last couple weeks.

For those that are unaware of the great strides Microsoft has made in the world of audit attestation, pay close attention to the additions and greatly enhanced Microsoft Trust Center. You can search services, location, and/or industry for compliance adherence.

I know several people over at Microsoft, and it is with sincere pleasure that I'm excited about the way that Microsoft is executing on using trust as a competitive differentiator. My hat is off. Excellent work. The cloud competitive market has no option but to respond. The speed with which Microsoft has built parity with Amazon's compliance technical marketing should be noticed.

Microsoft is serious about compliance and fully intends to capitalize on the investment that went into appealing to a broad market shaken by shifting regulatory requirements and frequent security breaches. What they have done isn't cheap. Or easy. But it will surely pay off.

Monday, May 23, 2016

PCI DSS v3.2 Spreadsheet Format

PCI DSS v3.2 Spreadsheet loaded here: https://sites.google.com/site/cloudauditcontrols.

May not be used for commercial purposes.

Monday, May 2, 2016

NIST to PCI DSS 3.1 Raw Map

Raw map. Details will be provided later. We feel this draft was very close. It's currently undergoing review by another external QSA and we have found just a few things to update. 

AC-01 Access Control Policy And Procedures 1.1, 7.1, 7.1.4, 7.3, 8.4, 8.8, 12.1, 12.1.1, 12.3, 12.4, 12.5.1, 12.5.5
AC-02 Account Management 1.1.5, 2.1, 6.3.1, 6.4.4, 7.1, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.2, 7.2.1, 7.2.2, 7.2.3, 8.1.3, 8.7, 8.1.4, 10.2, 10.2.5, 8.1.8, 8.5, 8.5.1, 8.6, 8.1.5, 10.6, 10.6.1
AC-03 Access Enforcement 7.1, 7.1.2, 7.2, 7.2.1, 7.2.2, 7.2.3, 8.1.5, 8.3, 10.4.2, 1.1.5
AC-04 Information Flow Enforcement 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.3.8
AC-05 Separation Of Duties 6.4.2
AC-06 Least Privilege 1.1.5, 7.1, 7.1.2, 7.1.4, 10.4.2, 7.1.1, 7.1.3, 10.2.2, 10.2.5
AC-07 Unsuccessful Login Attempts 8.1.6, 8.1.7
AC-11 Session Lock 8.1.8, 12.3.8
AC-12 Session Termination 8.1.8, 6.5.10, 12.3.8
AC-17 Remote Access 8.1.5, 12.3.8, 12.3.9, 12.3.10, 12.5.5, 2.3, 7.1, 7.1.1, 7.1.2, 7.1.3, 12.3
AC-18 Wireless Access 1.1.2, 2.1.1, 4.1.1, 12.3
AC-19 Access Control For Mobile Devices 4.2, 12.3, 12.3.1, 12.3.2, 12.3.3, 12.3.4, 12.3.5, 12.3.6, 12.3.7
AC-20 Use Of External Information  Systems 7.1.4, 12.8.2, 12.3, 4.2
AC-25 Reference Monitor 6.5.8
AT-01 Security Awareness And Training Policy And Procedures 12.1, 12.1.1, 12.3, 12.4, 12.5.1, 12.6
AT-02 Security Awareness Training 12.6.1
AT-03 Role-Based Security Training 12.6.1, 6.5, 9.9.3, 9.10
AT-04 Security Training Records 12.6.2
AU-01 Audit And Accountability Policy And Procedures 10.8, 12.1, 12.1.1, 12.3, 12.4, 12.5.1
AU-02 Audit Events 10.2, 10.2.1, 10.2.2, 10.2.3, 10.2.4, 10.2.5, 10.2.6, 10.2.7, A-1.3
AU-03 Content Of Audit Records 10.1, 10.3, 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6, A-1.3
AU-04 Audit Storage Capacity 10.7, 10.5.4
AU-05 Response To Audit Processing Failures DE-3.1, DE-3.3, DE-5.1
AU-06 Audit Review, Analysis, And Reporting 10.6.3, 12.10.1, 12.10.5, A-1.3, 10.6, 10.6.1, 10.6.2, 10.5.1, 10.5.2
AU-07 Audit Reduction And Report Generation 10.6
AU-08 Time Stamps 10.3.3, 10.4, 10.4.1, 10.4.3
AU-09 Protection Of Audit Information 10.5, 10.5.1, 10.5.2, 10.5.3
AU-11 Audit Record Retention 5.2, 10.7
AU-12 Audit Generation 10.2, 10.2.1, 10.2.2, 10.2.3, 10.2.4, 10.2.5, 10.2.6, 10.2.7, 10.1, 10.3, 10.3.6, 10.5.1
CA-01 Security Assessment And Authorization Policy And Procedures 11.6, 12.1, 12.1.1, 12.2, 12.3, 12.4, 12.5.1
CA-02 Security Assessments 6.3, 11.1, 11.2, 11.2.1, 11.2.2, 11.2.3, 11.3, 11.3.1, 11.3.2, 11.3.3, 11.3.4, 12.2
CA-03 System Interconnections A-1.2, DE-2.2, DE-3.3, 1.2.1
CA-05 Plan Of Action And Milestones 6.2, 11.2, 11.3, DE-1.1, DE-3.2
CA-06 Security Authorization, 7.1.4, 12.3.1, 1.3.8, 3.5.1, 3.5.3, 6.4.5, 7.1
CA-07 Continuous Monitoring 11.2, 11.3, DE-1.2, DE-1.3, DE-3.3, 11.2.1, 11.2.2, 11.2.3, 11.3.1, 11.3.2, 11.3.3, 11.3.4
CA-08 Penetration Testing 11.3, 11.3.1, 11.3.2, 11.3.3, 11.3.4
CA-09 Internal System Connections 1.1, 1.1.1, 1.1.2, 1.1.3, 1.1.6
CM-01 Configuration Management Policy And Procedures 1.1, 2.5, 6.7, 12.1, 12.1.1, 12.3, 12.4, 12.5.1
CM-02 Baseline Configuration 1.1.2, 1.2.2, 2.2, 2.2.4, 1.1.7,
CM-03 Configuration Change Control 1.1.1, 6.4, 6.4.5,
CM-04 Security Impact Analysis 6.4.5,,, 6.6, DE-2.1, DE-2.2, DE-2.2.1, DE-2.3, DE-2.4, DE-2.5, DE-3.3, 6.4, 6.4.1
CM-05 Access Restrictions For Change 6.4.2, 7.1.2
CM-06 Configuration Settings 2.2, 2.2.3, 2.2.4, 8.7
CM-07 Least Functionality 2.2.1, 2.2.2, 2.2.5, 6.6, 1.1.6
CM-08 Information System Component Inventory 2.4, 9.9.1, 11.1.1
CM-09 Configuration Management Plan 2.2
CP-01 Contingency Planning Policy And Procedures 12.10.1, 12.10.6
CP-02 Contingency Plan 12.10.1, 12.10.3, 12.10.6, 12.3.3
CP-03 Contingency Training 12.10.4
CP-04 Contingency Plan Testing 12.10.4
CP-09 Information System Backup 9.5.1, 12.10.1
CP-10 Information System Recovery And Reconstitution
IA-01 Identification And Authentication Policy And Procedures 8.1, 8.2, 8.8, 12.1, 12.1.1, 12.3, 12.4, 12.5.1, 12.5.4
IA-02 Identification And Authentication (Organizational Users) 8.1.1, 8.2, 8.3
IA-03 Device Identification And Authentication 9.1.2
IA-04 Identifier Management 8.1.1, 8.1.2, 12.5.4, 7.1.4, 12.3.10, 8.5.1
IA-05 Authenticator Management 2.1, 2.1.1, 2.2, 6.4.4, 8.2.1, 8.2.2, 8.4, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 4.1, 6.3.1
IA-06 Authenticator Feedback 6.5.5
IA-08 Identification And Authentication (Non-Organizational Users) 8.5.1
IR-01 Incident Response Policy And Procedures 12.1, 12.1.1, 12.3, 12.4, 12.5.1, 12.5.3
IR-02 Incident Response Training 12.10.4
IR-03 Incident Response Testing 12.10.2
IR-04 Incident Handling 11.1.2, 12.10.4, 12.10.6
IR-05 Incident Monitoring 12.10.6
IR-06 Incident Reporting 12.10.1
IR-07 Incident Response Assistance 12.5.3
IR-08 Incident Response Plan 12.10, 12.10.1, 12.10.3, A-1.4
MA-01 System Maintenance Policy And Procedures 12.1, 12.1.1, 12.3, 12.4, 12.5.1
MA-02 Controlled Maintenance 1.1.1, 6.5.4,,,,, DE-2.2.1, DE-3.3
MA-04 Nonlocal Maintenance 8.1.5, 8.3, 8.5.1, 12.3.8, 12.3.9
MA-05 Maintenance Personnel 12.8.3
MP-01 Media Protection Policy And Procedures 9.6, 12.1, 12.1.1, 12.3, 12.4, 12.5.1
MP-02 Media Access 9.7
MP-03 Media Marking 9.6.1
MP-04 Media Storage 9.5, 9.6.3, 9.7, 9.7.1
MP-05 Media Transport 9.6.2
MP-06 Media Sanitization 9.8, 9.8.1, 9.8.2
MP-07 Media Use 12.3, 12.3.5
PC-01 Limit Cardholder Data Storage 3.1
PC-02 Sensitive Authentication Data 3.2,3.2.1,3.2.2,3.2.3
PC-03 Displayed Primary Account Number 3.3
PC-04 Stored Primary Account Number 3.4,3.4.1
PC-05 Cryptographic Key Protection 3.5,3.5.1,3.5.2,3.5.3
PC-06 Cryptographic Key Management Processes 3.6,3.6.1,3.6.2,3.6.3,3.6.4,3.6.5,3.6.6,3.6.7,3.6.8
PC-07 Stored Cardholder Data Protection Policies 3.7
PC-08 Remove Common Coding Vulnerabilities 6.5,6.5.1,6.5.2,6.5.3,6.5.4,6.5.5,6.5.6,6.5.7,6.5.8,6.5.9,6.5.10
PE-01 Physical And Environmental Protection Policy And Procedures 9.10, 12.1, 12.1.1, 12.3, 12.4, 12.5.1
PE-02 Physical Access Authorizations 9.2, 9.3, 9.4, 9.4.1, 9.4.2, 9.4.3
PE-03 Physical Access Control 9.1, 9.1.1, 9.1.2, 9.1.3, 9.2, 9.9, 9.9.2
PE-04 Access Control For Transmission Medium 9.1.2, 9.1.3
PE-05 Access Control For Output Devices 12.3, 9.5, 12.3.3, 12.3.4
PE-06 Monitoring Physical Access 9.1.1
PE-08 Visitor Access Records 9.4.4
PL-01 Security Planning Policy And Procedures 12.1, 12.1.1, 12.3, 12.4, 12.5.1
PM-01 Information Security Program Plan 12.1, 12.1.1, 12.5
PM-02 Senior Information Security Officer 12.5
PM-04 Plan Of Action And Milestones Process DE-3.2
PM-05 Information System Inventory 2.4, 9.9.1, 11.1.1
PM-08 Critical Infrastructure Plan 12.2, 12.3
PM-09 Risk Management Strategy 12.2
PM-10 Security Authorization Process 12.3.1
PM-11 Mission/Business Process Definition 12.2
PM-13 Information Security Workforce DE-1.3, DE-3.3
PM-14 Testing, Training, And Monitoring 12.10.4
PM-15 Contacts With Security Groups And Associations 12.5.2, 6.1
PS-01 Personnel Security Policy And Procedures 12.1, 12.1.1, 12.3, 12.4, 12.5.1
PS-02 Position Risk Designation 7.1
PS-03 Personnel Screening 12.7
PS-04 Personnel Termination 9.3
PS-06 Access Agreements 12.3.5
RA-01 Risk Assessment Policy And Procedures 6.1, 6.3.2, 6.5.6, 6.6, 11.2, 11.2.1, 11.2.2, 11.2.3, 11.3, 11.3.1, 11.3.2, 11.3.3, 11.3.4, 11.6, 12.1, 12.1.1, 12.2, 12.3, 12.4, 12.5.1
RA-02 Security Categorization 3.1, DE-2.5, DE-2.5.1
RA-03 Risk Assessment 6.1, 6.3.2, 6.5.6, 6.6, 11.2, 11.2.1, 11.2.2, 11.2.3, 11.3, 11.3.1, 11.3.2, 11.3.3, 11.3.4, 12.2, DE-2.2
RA-05 Vulnerability Scanning 6.3.2, 11.2, 11.2.1, 11.2.2, 11.2.3
SA-01 System And Services Acquisition Policy And Procedures 12.1, 12.1.1, 12.3, 12.4, 12.5.1
SA-04 Acquisition Process 6.3
SA-09 External Information System Services 2.6, 8.5.1, 12.8, 12.8.2, 12.8.5, A-1, A-1.2, 12.8.3, 12.8.4, 12.8.1, 12.9
SA-10 Developer Configuration Management 6.3.2, 6.4, 6.4.5,,,,
SA-11 Developer Security Testing And Evaluation 6.3, 6.3.2, 6.5.3
SA-15 Development Process, Standards, And Tools 6.4.3
SA-18 Tamper Resistance And Detection 9.9, 9.9.2
SC-01 System And Communications Protection Policy And Procedures 1.5, 3.7, 4.3, 12.1, 12.1.1, 12.3, 12.4, 12.5.1
SC-02 Application Partitioning 8.7
SC-07 Boundary Protection 1.1.4, 1.2.3, 1.3.4, 6.6, 1.2, 1.1.2, 1.2.1, 1.3.1, 1.3.2, 1.3.3, 1.4, A-1.1
SC-08 Transmission Confidentiality And Integrity 4.1, 4.1.1, 6.5.4
SC-10 Network Disconnect 8.1.8, 12.3.8
SC-12 Cryptographic Key Establishment And Management 3.5, 3.5.1, 3.5.2, 3.5.3, 3.6, 3.6.1, 3.6.2, 3.6.3, 3.6.4, 3.6.5, 3.6.6, 3.6.7, 3.6.8
SC-13 Cryptographic Protection 3.5, 3.6, 4.1, 4.2, 4.3
SC-28 Protection Of Information At Rest 3.4, 3.7, 6.5.3
SC-39 Process Isolation A-1.1
SC-43 Usage Restrictions 12.3, 12.3.1, 12.3.2, 12.3.3, 12.3.4, 12.3.5, 12.3.6, 12.3.7
SI-01 System And Information Integrity Policy And Procedures 5.4, 12.1, 12.1.1, 12.3, 12.4, 12.5.1
SI-02 Flaw Remediation 6.1, 6.2, 6.5.6, 11.2, 11.2.1, 11.2.2, 11.2.3, 11.3.3
SI-03 Malicious Code Protection 5.1, 5.1.1, 5.1.2, 5.2, 5.3, 6.6, 11.4, DE-5.1
SI-04 Information System Monitoring 6.6, 11.4, DE-5.1, 5.2, 12.10.5, 11.1, 10.6, 10.6.1, 10.6.2
SI-05 Security Alerts, Advisories, And Directives 12.5.2
SI-07 Software, Firmware, And Information Integrity 10.5.5, 11.5, 11.5.1, 10.5, 12.10.5
SI-10 Information Input Validation 6.5.1, 6.5.2, 6.5.7, 6.5.9
SI-11 Error Handling 6.5.5
SI-12 Information Handling And Retention 3.1

Wednesday, April 20, 2016

Quick and Dirty Cloud Assessment

Some of you guys have insane resources, capital, people, that you can throw at the problem until it's solved.

Unfortunately, that's not all of you. Or maybe it IS you, but you're not going to spend anymore time than necessary to make sure that you have the basics covered.

Here's the short list.

1. Review the following list of security solutions and make sure that you have answers for each one of the security solutions/products that apply to you.


2. Find the hardening guide for each one of the products that you have installed and make sure you focus on reducing the attack surface and exploitability of the systems by implementing moderate to complete hardening on the systems.

3. Ensure that you have basic segmentation implemented to protect multitier applications.

4. Implement traffic filtering for external-facing applications. I'm a big fan of these guys. No affiliation whatsoever. Look at some of the other offerings that they have as well.


If you want one of the best peer-reviewed security standards that I believe is actionable and reasonable to implement, consider PCI DSS. There is some overlap between some of the requirements. It still requires a moderate amount of interpretation. I've done a tremendous amount of work in and around the standard, and I'm not speaking flippantly or borrowing from someone else's opinion when I state these things.

Here's a short blog post that contains distilled requirements that I consider must-haves:


5. Final additional considerations not required specifically by most regulations and standards. [a] Consider Network Behavior Anomaly Detection such as Fire Eye. [b] Consider white listing, sandboxing, persistence, and other measures to limit attack surface, attack vectors, escalations, attack persistence.

This is typically when I tell organizations that are uncomfortable making product decisions to engage a reputable security-focused reseller. Of course I have my favorites for different situations. But I don't know your environment. My brother founded and runs https://www.criticalstart.com. I've used some of his guys in the past for different assessments. Good work. Another couple that I like are https://www.redlegg.com and https://depthsecurity.com. Both founded by stand-up guys that care about the customer and care about getting it right.