Research

I have bunch of random research thoughts I am working on. I think they are building into a cohesive whole but cannot make any promises. I’m branding these forming ideas as my “research scratchpad”, and will appreciate any feedback. Yesterday, while working with a client, I was asked to define Software Defined Security. This won’t be that post, but as part of discussing the definition and characteristics we got into another concept that has really been standing out to me for a while, and I suspect is on the verge of changing in a big way. Early security was pretty much just another aspect of infrastructure. Access controls, networking, and our minimal other controls were built into the infrastructure. This started changing in the 90’s, into what I call our “outside looking in” posture. The vast majority of security controls starting moving to external tools that are often desynchronized from the underlying infrastructure. This isn’t an absolute rule – the balance has shifted materially to a security control layer, not merely a security management layer… added to infrastructure, not necessarily embedded within it. A heck of a lot of our security involves cutting wires between boxes and inserting new boxes, or adding software agents where no one really wants them. This was a natural, proper evolution – not a mistake or stupidity. It was all we had. But the cloud and virtualization blow this apart in two ways: We are regaining hooks, thanks to APIs, into the infrastructure itself. The security management plane doesn’t necessarily need to be as decoupled as in ‘traditional’ infrastructure architectures. We are losing the ability to insert external security controls into the infrastructure. Adding these integration/choke points adds performance and functional costs beyond those we have learned to generally work around over the past couple decades. The ability to manage large swatches of infrastructure security using the same tools, techniques, and interfaces as those building and maintaining the infrastructure is a major opportunity to remediate many perceived shortcomings of existing security methods. Share:

A key aspect of business today is the extended enterprise. That’s a fancy way of saying no organization does it alone anymore. They have upstream suppliers who help produce whatever it is they produce. They have downstream distribution channels that help them sell whatever needs to be sold. They outsource business processes to third parties who can handle them better and more cheaply. With the advent of advanced communication and collaboration tools, teams work on projects even if they don’t work for the same company or reside on the same continent. Jack Welch coined the term “boundaryless organizations” back in 1990 to describe an organization that is not defined by, or limited to, horizontal, vertical, or external boundaries imposed by a predefined structure. They are common today. In order to make the extended enterprise work, your trading partners need access to your critical information. And that’s where security folks tend to break out in hives. It’s hard enough to protect your networks, servers, and applications, while making sure your own employees don’t do anything stupid to leave you exposed. Imagine your risk – based not just on how you protect your information, but also on how well all your business partners protect their information and yours. Well, actually, you don’t have to imagine that – it’s reality. Let’s do a simple thought exercise to get a feel for the risk involved in one of these interconnected business processes. Let’s say that for cost reasons the decision was made to outsource software maintenance on legacy applications to an offshore provider. These applications run in your datacenter, and maintenance only involves pretty simple bug fixes. You can’t shut down the application, but it’s clearly not strategic. What’s the risk here? Start getting a feel for your exposure by asking some questions: Which of our networks do these developers have access to? How do they connect in? Who are the developers? Has the outsourcer done background checks on them? Are those checks trustworthy? What is the security posture of the outsourcer’s network? What kinds of devices do they use? Even if the developers are trustworthy, can you trust that their machines are not compromised? Yes, you can segment your network to ensure the developers only have access to the servers and code they are responsible for. You can scan devices on connection to your network to ensure they aren’t pwned. You can check the backgrounds of the developers yourself. You can even audit the outsourcer’s network. And you can still get compromised via business partners, because things move too fast to really stay on top of everything. It takes seconds for a machine to be compromised. With one compromised machine your adversary gains presence on your network and can then move laterally to other devices with more access than the developers have. This happens every day. The point is that you have very little visibility into trading partner networks, which means additional attack surface you don’t control. No one said this job was easy, did they? These interconnected business processes will happen whether you like it or not. Even if you think they pose unacceptable risk. You can stamp your feet and throw all the tantrums you want, but unless you can show a business decision maker that the risk of maintaining the connection is greater than the benefit of providing that access you are just Chicken Little. Again. So you need to do your due diligence to understand how each organization accessing your network increases your attack surface. You need a clear understanding of how much risk each of your trading partners presents. So you need to assess each partner and receive a notification of any issues which appear to put your networks at risk. We call this an Early Warning System, and external threat intelligence can give you a head start on knowing which attacks are heading your way. Here is an excerpt from our EWS paper to illuminate the concept. You can shrink the window of exploitation by leveraging cutting-edge research to help focus your efforts more effectively, by looking in the places attackers are most likely to strike. You need an Early Warning System (EWS) for perspective on what is coming at you. None of this is new. Law enforcement has been doing this, well, forever. The goal is to penetrate the adversary, learn their methods, and take action before an attack. Even in security there is a lot of precedent for this kind of approach. Back at TruSecure (now part of Verizon Business) over a decade ago, the security program was based on performing external threat research and using it to prioritize the controls to be implemented to address imminent attacks. Amazingly enough it worked. Following up our initial EWS research, we delved into a few different aspects of threat intelligence, which provides the external content of the EWS. There is Network-based Threat Intelligence and Email-based Threat Intelligence, but both of those sources are more about what’s happening on your networks and with your brands. These really help you understand what’s happening on your partner networks, which clearly pose a risk to your environment. So we are spinning up a new series to continue our threat intelligence arc. This series is called Ecosystem Threat Intelligence and will delve into how to systematically assess your extended network of trading partners to understand the risk they present. Armed with that information you will finally have the information to block a trading partner or tune your defenses based on the risk they pose. As with all our research, we will focus on tangible solutions that can be implemented now, while positioning yourself for future advances. As a reminder, we develop our research using our Totally Transparent Research methodology to make sure you all have an opportunity to let us know when we are right – and more importantly when we are wrong. Finally, we would like to thank BitSight Technologies for potentially licensing the paper at the end of this process. Our next post will delve into the types of information you need to assess your trading partners, and how it