NIST SP 800-53 r4 to CJIS v5.4 Control Mapping

Reverse mapped CJIS control set into NIST 800-53 controls as the new baseline.

Download here.

State Security Model Flaws – or… Assumptions

This is meant to be a short, simple post. Just capturing interesting discussion from our class the other night. The state security model is really simple, representing an easy way to describe the importance of governance. Provision, configure, validate to a known good state. Monitors state deviations. Known state deviations are good and mean that you are still in a known good state. Unknown state deviations must be investigated (response) to determine whether it is a new known state deviation or an incident.

However, some really good points were brought up during class. There's a lot of assumptions on external factors introducing the errors from the way that several people have presented and discussed the model. We learned this model in the military, and the source of the deviation could be assumed to be internal or external. It didn't matter.

The reality is that your definition of a known good state may or may not be absolute (100%). Your visibility into the system is almost certainly not absolute. Examples include running firmware, existing compromise, individual configurations, account access, authenticator systems, cipher code/implementation/system, source code, system interoperability/API configurations/capabilities/hidden capabilities...

If we presume that assurance of a known good state is based upon a selection of points that you can validate, then how many points are good enough to provide assurance of a known good state? What about the periodicity? Is there anything here we need to consider?

Systems themselves could *possibly* introduce errors within the bounds of allowed operations. People most certainly can. Component visibility can inhibit your view/understanding of actual state. Your view/understanding of actual state can change between timed points of inspection. External and/or internal actors may identify vulnerabilities in code and exploit that within the bounds of your controls.

The point of the discussion is that models can be very powerful, and certainly helpful for understanding systems through a particular lens. Think outside the box. Don't be afraid to ask questions. The person who initiated the discussion is perhaps one of the least technical people in the class, just asking innocent questions.

How do you address the concerns? Short answer. Build the system with enough introspection and visibility into critical processes/configurations that overcomes your risk tolerance. Make the assumption that the system is already compromised and build it so that you can identify an existing compromise to the extent possible. Strong emphasis on access controls, not repudiated auditing, visibility into communications including who/what/where/why/how/volume.

Spreadsheet: FBI Cloud Control Catalog – Appendix A

Here's the spreadsheet version, cleaned up, of the FBI Criminal Justice Information Systems (CJIS) Security Policy - CJIS Cloud Control Catalog.

► Download spreadsheet version here.

HIPAA Technical Control & Assessment Links

Go to the documents tab to find spreadsheet versions of the below.

• NIST HIPAA Security Rule Toolkit
  http://scap.nist.gov/hipaa/
• Security Risk Assessment Tool (SRA Tool)
  https://www.healthit.gov/providers-professionals/security-risk-assessment-tool
• Technical Safeguards [DOCX - 240 KB]
  https://www.healthit.gov/sites/default/files/20140320_sratool_content_-_technical_volume_v1.docx
• Top 10 Tips for Cybersecurity in Health Care
  https://www.healthit.gov/providers-professionals-newsroom/top-10-tips-cybersecurity-health-care

Recent discussions… Capturing some of that here. Some of the more important links to technical assessment information is above. Services are actually easy to build, as long as you simplify the approach. Has everything to do with scope, stating assumptions, and setting expectations.

By the way – yes, I downloaded and reviewed the current version of the HITRUST framework.

On another note, HITECH  has nothing to do with technical controls and is an unfortunate name. It's confusing, but it's entire focus is enforcement – putting teeth into HIPAA using financial penalties as an incentive. Please do not use it out of context.

Still Relevant – Sales Engineering Lessons Learned

Found a document where I captured some of the quick lessons I learned experienced in the first year working as a presales engineer. 9 years later, these are still relevant.

SE Lessons Learned

1. Be genuine. You have to learn who you are and be comfortable. It really doesn’t matter what you’ve done or who you know. When you’re in front a new customer, they don’t know you, and you are beginning from scratch. It’s OK to befriend them, and you should, but…
2. Develop relationships slowly. This isn’t a race to be the most likeable guy. Take your time. Be accessible, be open, make friends, but in the end you have to make the sale. Never lose sight of your end goal or you will become ineffective and too involved to make decisions.
• This isn’t a buddy-buddy game. It’s about genuinely helping someone with a project and helping your customer to close a sale. This means…
3. Don’t spill the beans. Let the customer learn what they need to know slowly. This does two things and prepares you for the next point.
• First, the customer needs the information they believe is most important to them. Although, there is an education component of the sale, you have to address the pieces that are most important to the customer. Regardless of why they believe what they believe – They do, and you have to address that first.
• Second, the customer shouldn’t be overloaded with information they don’t care about. It’s nice that you know your field so well, or that you anticipate a question about something down the road. Carefully scope how much information you give them, and they can continue coming back to you for more. It’s not about withholding information – it’s about not giving away the cards completely.
4. Never talk down to your competition. It’s great that you have a superior product. If you don’t, then you should move to a company you believe in. However:
• You don’t know these people as well as you think you do, where they come from, who their friends are, or what competition has a particular feature they actually see as superior. It doesn’t matter if they are right or wrong in their own assumptions. They have friends and opinions and you have to respect this. Instead of bashing the competition…
5. Consider alternatives to talking down to your competitors. This doesn’t mean you can’t say a word. You can express an opinion:
• Offer to go head to head during an evaluation and absolutely speak to your previous successes going head to head. Let your actions speak louder than your words.
• Speak to your product’s strengths and not against specific product weaknesses. Speak to weaknesses broadly as a class of product if you’re asked about it.
6. Ultimately, you have to focus on the end-result. Sell product.
• Your job isn’t about making the best documentation possible, the best friends possible, or doing anything else that doesn’t contribute to the bottom line of your success. Perfectionists beware. It’s good to have drive and work hard – but spend the energy perfecting the sales process, not anything else that takes time from you taking care of current customers and helping your sales manager get into more accounts.
7. Nobody cares how much you know. People want to know how much you care. Try to understand the customer’s problems and spend time recognizing the strengths of the people you’re working with. They will learn how good you are over time.
8. Communicate. As much as the technology you know, your role is in sales.
• Stay in touch with your sales manager and escalate issues to him before he’s blindsided with an account that he thinks is going well.
• Stay in touch with your sales channel counterparts. Other SEs should:
• think of your solution when they visit a customer
• speak to your solutions strengths
• defend your solution when challenged in the competitive landscape. 
9. Read books. You don’t know yourself and others as well as you think you do. Learn what others are interested in and read a book about it. Read about sales. Read about relationships. Read about your industry or a new technology. Read. Read. Read.
10. Under promise and over deliver. Always do this. Develop a reputation for delivering on what you promise. This builds trust faster than anything else. You need to finish a few tasks well – not perfect – rather than fail miserably in trying to complete several tasks.
11. Never underestimate politics. Political relationships drive important decisions whether you are involved in the process or not. Some people will like you as long as you are useful to them and don’t get in their way. Nobody likes to be overshadowed. People want to know you are willing to help them and will back them up. When you start doing well, the way you handle your success will determine the reaction and support of those around you that aren’t doing as well.

Machine Learning – Intelligent Security Data Analytics

Ran across a fascinating TED video which provides insight into just a close we are to meaningful security data analytics.

Machine learning systems within the last year now process images, signs, and information with more accuracy than a human. The extraordinary Deep Learning algorithm allows scientists to build learning systems without prior knowledge of the subject and solve previously unsolvable problems. Unsolvable… not because of computational power limitations… but because people don’t know how to solve the problem. The machine, however, can learn about and figure out new ways of solving problems that people have not yet thought about. This is different from programmatically writing the logic for how to solve problems.

Consider speed and analysis of system operations with accuracy and capability beyond what a human being can process, scaled to consume the entire output of the data centers operational output (errors, logs, alerts). This is beyond building rules to identify bad traffic and malicious events. This is about enabling a deep learning machine to read every known book, website, web forum, data feed, dark web content, and become a security powerhouse with ultimate knowledge of your data center.

Sound crazy? Far-off? Watch the video below.

The Wonderful and Terrifying Implications of Computers That Can Learn

Jeremy Howard
 

The Emerging Recognition of Governance

Thank you Verizon. Fantastic report. The authors did a wonderful job and my hat is off to you. Thank you Dark Reading. Thank you twit.

Governance really is THAT important.

Security used to look something like this… https://www.youtube.com/watch?v=D0n8N98mpes. Then organizations started to focus on compliance when Sarbanes-Oxley and in PCI became mandatory and prevalent. Security professionals realized that compliance in and of itself wasn't enough, and the focus shifted to addressing risk. Problem is that people still feel like they are playing Wack-a-Mole. The governance problem started becoming… A problem. It grew geometrically with the number of different new systems, vendors, applications, interconnections, interfaces, and dependencies.

During the lifecycle of the system there are different security and risk challenges that must be solved, such as those described in context of a PCVMR Cycle, which recognizes the importance of maintaining the system over time.

Let's look at operational hygiene, or governance, in the lands of a state security model. You start at the 0 when the system has been validated/authorized for operations. Ideally at that moment in time the system is fully secure without any flaws. You've tested the system against known attacks and established that the system is properly secured to your baselines. Over time, however, the adjusted state for where you should be is a slight trajectory upwards with some growth to recognize changes in security posture/configurations, architecture, design, firmware, patches, control inheritance, additional solutions, etc.

Compare the state of where you should be vs. the day 0 configuration and what you find is that over time you have a greater gap. Let's call this current state vs. secure state gap "drift". The drift/gap gets larger over time, and leaves you susceptible to compromise. Now go back and look at the wonderful statistics the Verizon team put together and read the column in red.

Does compliance = security? Depends. Depends on whether you recognize a properly implemented risk management framework as necessary to meeting the compliance requirements. Depends on whether you recognize compliance requirements must be managed over time. Depends on whether you have the right people who understand, processes that enforce, and tools that execute and track governance of your systems.

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.

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

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.

• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
• Security and Privacy Controls for Federal Information Systems and Organizations

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.

• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf
• Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans