Interestingly enough however, many of the organizations quoted in the BT study expect that they are less likely to get hacked if they pen test. But unless you have unlimited resources and endless stretches of time, that conclusion is very wrong.

In reality, the amount of resources that most organizations have to dedicate to pen testing is limited. According to the DarkReading article, this happens for a variety of reasons; everything from upper management not understanding the importance of pen testing to organizations worrying that “the results of a pen test ‘could be embarrassing’” causes vulnerable systems to go untested. But no matter what the reason, the bottom line is that this issue is only going to become more prominent as the role of technology in organizations continues to expand.  

So, if there’s no avoiding the fact that we should expect to get hacked even if we pen test, what should we do? Easy: Find out what we can do to minimize the impact of compromises and continue to make sure we have a strong foundation to work on.

This idea goes back to one of the ongoing themes we have here on the site, which is getting back to basics and doing them well. Start out by identifying what you are trying to protect and work your way out—take a defense in-depth approach. Most organizations are looking to protect data, so that’s where we’ll start.

First, we need to determine the sensitivity of the data we are trying to protect. What would happen if a hacker, competitor, or nation-state was able to get to that information? Would lives be at stake? Would the loss of a competitive advantage result in losing a contract? How much would it cost to clean up after your customers’ credit card details were sold on the web?

Based on this data value analysis, say you come up with three sets of data: A, B, and C, with A being your crown jewels. Maybe it would make sense to store the A set in a segmented area of the network where you need to log into a special terminal for access. Perhaps the B set could exist on your organization’s intranet protected by traditional OS and network access controls. The C set may not be too sensitive, so maybe it’s available in public areas on your intranet.

In this instance, an attacker may be able to get through your first line of defense and into your intranet. Any information stolen there wouldn’t be too sensitive, so the effect of compromised data would be minimized. Maybe the hacker is very skilled and is able to bruteforce someone’s password over a period of several weeks. They’ve broken through you second layer of defense and now have access to the B set of data. Although this data is more sensitive, the required skills and time commitment necessary to gain access to this information may minimize the compromise if the data is time sensitive. Finally, you have the
A data set. In this case, the attacker would not only have had to access the intranet and compromised someone’s account, but would have also had to physically gain access to a secured terminal. The hope is that at this point, the attacker will give up and focus on a less secured target.

You can make this scenario a lot more complex, but this example illustrates the basic concept of assuming you are going to get hacked and using defense in-depth to segment your network and employ protections relative to the value of the compartmentalized data.

Besides disconnecting your organization’s network from the Internet completely, this is the best that I could come up with. What are your thoughts on how we can minimize the effects of getting hacked? Comment below or send me a tweet @grecs.

o     o     o     o     o

One of the best ways to get back to basics is to have a good foundation. We’ve put together a list of useful books that will help you get on track and do the basics well.  

If you have any recommendations for local security bloggers that we should keep our eye on, leave a comment below or send us a tweet @grecs.

#3 – More Than 140: Opening his post with the dilemma of needing more than 140 characters to answer a question about embedded devices via Twitter, @cyberhiker decided to write a blog post about it instead. Discussing some of the drawbacks of embedded devices, @cyberhiker wrote that “[embedded] devices will never have the security controls that full blown operating systems and applications are capable of implementing.” (Sorry, Microsoft haters.) @cyberhiker then offers some helpful tips about how to test embedded devices and make them secure as possible. If you’d like to read the full post, you can view it here.    

#2 – The Cybersecurity Act in Two Parts: (Note: While @rybolov actually wrote two separate posts dealing with the Cybersecurity Act of 2009, they were a “Part 1” and “Part 2” kind of deal, so we’re counting them as one post, just FYI). In his post(s) about the Cybersecurity Act of 2009, @rybolov talks about the nuts-and-bolts of the Cybersecurity Act and what kinds of changes (both good and bad) the Act will bring about. The especially nice thing about these two posts is that @rybolov lists the different sections of the Cybersecurity Act and then comments on them, giving them his own “verdict.” This is definitely an important read for anyone in the security industry, as many of these changes have the potential to make some changes to the way we’re currently doing things. You can read “Part 1” and “Part 2” on the Guerilla CISO blog.

#1 – Back to Basics: Marcus J. Carey has been on a roll this week, taking our number one slot for his v-blog post “The Secret to Troubleshooting: Thin-slicing.” To be honest, we would have given all of our slots to Marcus this week not only because because his v-blogs are hilarious, but also because a lot of what he has to say resonates with our own beliefs about security. In his post “The Secret to Troubleshooting: Thin-slicing,” he addresses one of the most important parts of security: The basics. He says in his post that knowing the basics about something can help eliminate what could become bigger issues. He also makes another great point, saying that people will often try and find complex solutions to complex problems when really, if they just did the basics well, they would prevent a lot of those complex problems. You can watch the full post here.

Bonus: While we couldn’t give Marcus every slot, we did want to highlight some his additional v-blog posts this week, specifically his “Selling Security” and “Ham Security” posts. The “Ham Security” post is especially poignant as it shows why people shouldn’t always do things the same way simply because “that’s the way it’s always been done.” The “Selling Security” post is a good watch, especially for those of us who have to “sell” good security to our management. It’s about not assuming that management will just “give it to you:” You may need to approach them several times.

Well, that’s all for this week—as always, feel free to comment or send us a tweet @grecs.

###

Do you have your pass to SANSFIRE yet? If not, why not purchase it through NovaInfosecPortal? It doesn’t cost you anything extra, and it helps us keep the site going.