tCell by Rapid7
Managed Detection & Response (MDR)
Managed Vulnerability Management
Managed Application Security
Incident Response Services
Penetration Testing Services
IoT Security Services
Training & Certification
Find a Partner
Rapid7 Insight is your home for SecOps, equipping you with the visibility, analytics, and automation you need to unite your teams and amplify efficiency.
Insight Cloud Overview Try Now
User Behavior Analytics & SIEM
Dynamic Application Security Testing
Orchestration & Automation
Application Security On-Premise
Application Monitoring & Protection
Need a hand with your security program? From planning and strategy to full service support, our experts have you covered.
Need immediate help with a breach?
In this Whiteboard Wednesday, Trey Ford, Global Security Strategist at Rapid7 will discuss the NIST Cybersecurity Framework that was released on February 12, 2014 by President Obama to help protect critical infrastructure. Watch this video to get a quick overview of the framework set forth.
Hi, I'm Trey Ford, global security strategist with Rapid7. This week's Whiteboard Wednesday we're going to talk about the cyber security framework released by NIST. On February 12, 2013 President Obama issued Executive Order 13636 basically improving critical infrastructure cybersecurity. Exactly one year later, NIST released a voluntary framework on February 12, 2014. It took a year to get this together. This is meant to be a living document. I think this is unlike other certain regulatory bodies that we're working with that we don't really have the option of using - PCI, Sarbanes-Oxley, HIPAA. This is meant to be a general overview framework that allows us to organize some thoughts and work towards being able to better communicate the posture of our cyber security strategy.
I think a couple of things about this are innovative. We're going to tear these apart in upcoming Whiteboard Wednesdays and blog posts, but I want to give a real quick overview of what this means. They break this process down into identify, protect, detect, respond, and recover.
Identification, I think laughably, is an important place to start. Some organizations deal a lot with mergers and acquisitions. You're acquiring new systems, new environments. You don't know what you're getting. I think a lot of times this is something we spend a lot of time doing inside of our own networks is scanning and discovering devices, getting an idea not just of what assets we have under management but what assets probably don't belong on our network. Finding out what all we have, verifying that we know where centers of gravity important data sets or critical assets live. The identification process should be an ongoing loop. This is called out and described fairly carefully in this framework.
Next is protect. Once you know where all your eggs are, you can move them into a basket. Then, you work on defending them. This allows you to simplify your approach to defense. It allows you to save some investment, some money, some budget on how you're protecting. You don't have to protect everything the same way. I would make the reference to Fort Knox security. Unless you're protecting gold, you may not need to protect it as aggressively.
You've identified assets. You're protecting what's important. Then, there's the detection piece. Once you've identified assets, centralized them, and started to build protection around them, then you have choke points. You have logical places to make sure you're gathering logs, setting baseline behavioral patterns, and getting an idea of what normal looks like so you can identify anomalies. You can identify things that look out of place. It simplifies what all you have to investigate.
Response is important. The illustration we have here is a fire chief going through doing a fire code inspection. Checklists are fairly important, fairly useful. We do this today with other regulatory frameworks, but they're calling out a communications plan, this notion that if and when. It's not if and when but where and how something's going to happen that you're prepared, that you have a framework. You have an approach not just to cleaning out a miscreant but also being able to go through a clean communications plan for internal, if necessary external, communications and then a process to make sure you're folding in lessons learned in the recovery process. It's not just about making sure you get back to a trusted computing platform, getting back to a known good computing state, but also folding those lessons learned building that back into your protection and detection strategies making sure you learn recover and execute better in the future.
Thanks for tuning in. We'll see you next week
Looking to implement the CIS top 20 critical security controls? Download our free toolkit.