Agile Security Manifesto: 12 Core Principles forSecurity for the Real WorldThe principles in this paper take into account the fact that today’s environment is an ever-expanding and changing combination of services, devices, and software that are created, utilized, evolved, and discarded daily. They are based on the foundation that companies must learn to See Learn Adapt Act™ in order to achieve Agile Security®.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Agile Security Manifesto #1 - Be More Adaptive than Our Adversaries . . . . . . . . . . . . . . . . . . . . . . 1

Agile Security Manifesto #2 - Security Must be as Dynamic as Threats, Environments . . . . . . . 3

Agile Security Manifesto #3 - No Such Thing as a Trusted Network or Device . . . . . . . . . . . . . . . 4

Agile Security Manifesto #4 – Offensive Research Has Limited Immediate Value . . . . . . . . . . . . 5

Agile Security Manifesto #5 - You Can’t Protect What You Can’t See . . . . . . . . . . . . . . . . . . . . . . . 6

Agile Security Manifesto #6 - Dynamic IT Environments Need Dynamic Intelligence . . . . . . . . . 7

Agile Security Manifesto #7 - Beware of the Black Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Agile Security Manifesto #8 - Every Environment is Unique; Adapt Defenses Quickly . . . . . . . . 9

Agile Security Manifesto #9 - Security is Not an Aggregation of Policies or Checkboxes . . . . 10

Agile Security Manifesto #10 - Security is a ‘Big Data’ Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Agile Security Manifesto #11 - Security is a People Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Agile Security Manifesto #12 - Security Must Be An Enabler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1

INTRODUCTIONWe have seen numerous attempts over the past 30 years to solve the security “problem,” but the truth is,this isn’t a problem as much as it is a reality. In the quest for a “solution,” companies—and even entire industries—have come and gone, regulations and compliance groups have attempted to set standards, academics have searched for perfection, and even the once “unexploitable” have fallen.

Every year new attempts at “solving this problem” are launched and all too often they lack an understanding of the challenges that exist. If any further indication of this trend is needed, have a look at the emergence of advanced persistent threats (APT) and the myriad of solutions claiming to solve it.

With this situation at hand, Sourcefire harnessed its collective experience to develop the 12 core principles that make up our Agile Security Manifesto. This Manifesto defines our philosophy on how to approach security in today’s real world.

The principles in this paper take into account the fact that today’s environment is an ever-expanding and changing combination of services, devices, and software that are created, utilized, evolved, and discarded daily. They are based on the foundation that companies must learn to See Learn Adapt Act™ in order to achieve Agile Security®.

The reality of defending these types of systems requires that we understand, and think deeply, about how we operate. We believe the notion of a “trusted network” is a fairy tale, there is no magic black box or silver bullet solution to the security problem, and current security research is off the mark.

The considerations in this white paper define an important baseline that will help avoid many of the challenges encountered in order to secure networks and data in dynamic environments against equally dynamic threats.

As you read this paper, we hope it spurs you to create your own list of principles that will help further shape the industry and, more importantly, help your organization become more adaptive and dynamic in the way that it protects data.

AGILE SECURITY MANIFESTO #1 - BE MORE ADAPTIVE THAN OUR ADVERSARIESThe first principle of the Agile Security Manifesto is perhaps the most challenging: “The pursuit of security requires that we be more innovative and adaptive than our adversaries.”

We, as practitioners, must somehow find a way to outsmart the “bad guys.” The rub is that we have to do it in such a way that things appear to be normal to our users, they must feel unencumbered, free to do what they feel is right for them, for us and for the business.

This is the problem and, fundamentally, why we are at this point in our evolution. Collectively we have come to depend on technology and process to make our world what it is. These technologies and processes have become so important to the functioning of our world that we have wrapped them in more process and validated those processes with more technology. We have gone to extraordinary lengths to actively prevent change to these technologies in the misguided pursuit of stability.

“...this isn’t a problem as much as it is a reality. In

the quest for a “solution,” companies—and even entire industries—have

come and gone, regulations and compliance groups have attempted to set standards, academics have searched

for perfection, and even the once “unexploitable”

have fallen.”

1

2

So there we have it. Our misguided pursuit of stability has created our dependence on technology and the failures of that technology ultimately result in catastrophic ripples in our view of the world. We respond by being more regimented, introducing more processes, adding layers of monitoring, and saying “that will never happen again.”

We do not implement processes that allow us to operate in the presence of failure. We no longer have the ability to respond outside our processes and parameters because stability has prevented us from exploring the possibilities. Our prior successes in implementing this stability, wholly outside the presence of an adversary, has suppressed the need be innovative and adaptive and even the awareness that there is an adversary.

If you think about it in terms of real world analogues you might come up with this:

Squirrels are incredibly motivated to compromise bird feeders. Not because they are lazy but because the payoff is far greater than foraging around for nuts all day. If they get into that feeder they have weeks worth of food available and a consistent and reliable source to return to for it. The birds have food, too, just not as much.

In many ways this is the challenge we face: stopping the squirrels while allowing the birds to feed. We have to be more adaptive than the squirrels, be more innovative in approaching the problem, think outside of the box, or perhaps change how we design and protect the bird feeders.

Back to the principle: “The pursuit of security requires that we be more innovative and adaptive than our adversaries.” We are encumbered as practitioners by the need for stability and comfort. We must find ways to overcome these challenges before we can be more innovative and adaptive than our adversaries. We have to find the opportunities to innovate our defenses in ways that do not significantly impact our businesses and users. We have to take the time now to prepare for when the attack comes, be it a drive-by only looking for users’ financial information, or an attack targeted at your intellectual property and a stepping stone to the next target. We have to think of ways to know that the compromise is there, ways to force attackers into becoming known, without impacting our users.

To be more innovative and adaptive than our adversaries requires we know a lot more about our networks, users, applications, and weaknesses. As practitioners we have to test them, understand that they are what they were designed to be, and then find creative ways to mitigate risks, and we need to do it in such a way that our users are minimally affected. Only you can do this though, outsiders cannot do it for you. Only you are empowered to know these local weaknesses, unless of course the adversary is already there. We have to be able to mitigate these risks while others evaluate making appropriate changes and collectively we have to protect stability in the process.

In the end we must be more innovative and adaptive than our adversaries and the process of getting there will be a challenging one. While our technologies are a good step towards enabling adaptive defenses, it is nearly impossible to implement truly adaptive defenses in any measure of time that approximates “rapid.” The bottom line is that if you don’t start now you will surely discover that it is too late when you realize you truly need it.

“...The pursuit of security requires that we be more

innovative and adaptive than our adversaries.”

3

AGILE SECURITY MANIFESTO #2 - SECURITY MUST BE AS DYNAMIC AS THREATS, ENVIRONMENTSThe second principle of the Agile Security Manifesto is an interesting conundrum. We state, “Security technologies and operations must be as dynamic as the threats they face and the environments they are protecting.”

If you believe, as pointed out in the first principle, that part of our problem in securing environments is our pursuit of stability and success in achieving it, then you are going to be a little bewildered by the second principle. It is only natural to ask: How can I be as dynamic as the threats, unencumbered by process and a need for stability, and as dynamic as the stable unchanging environments I am charged with protecting?

This is a good question and it lets us talk about the problem in the right context. While the technology may be stable, the environments are anything but. There is no better recent example of this than the acknowledgment by the Department of Homeland Security (DHS), through Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), that systemic design “features” (failures to the purists among us) in industrial control systems are too common and too widely deployed to be routinely addressed through a rapid response system like ICS-CERT. This is an entirely practical acknowledgement that uncovers an inconvenient truth; we have to secure these systems in the presence of design features that were never intended to face an adversary.

For those of you charged with defending these stable ICS environments, things are not going to be static for long. The technology may not change very quickly but the threats you face may make the environment you protect a potentially exciting and challenging place to work. The adversaries are going to continue to look for opportunities and the researchers, having no viable and responsible outlet, are going to release their research publicly so we can take appropriate mitigating action. Stuck in the middle of this challenge are our customers, users, and us. We can see it coming and we need to build systems that can adapt at will, in the absence of clear direction, to maintain stability while others address correcting the fundamental problem.

“...regardless of the stability of the technology in the absence of an adversary, the environment and threats are dynamic.”

The second principle speaks directly to this situation. It acknowledges that regardless of the stability of the technology in the absence of an adversary, the environment and threats are dynamic. They are unquestionably at least as dynamic as the adversary intends them to appear to be. Take Stuxnet as an example of how the adversary can and does manage the dynamics of the environment. This was a tool designed to infiltrate, unbeknownst to the users, and silently degrade effectiveness while providing the appearance of stability. Had the adversary taken a different approach and caused chaos it would have been directly destructive and not deviantly destructive. They clearly didn’t want the environment to be too dynamic and also clearly had the ability to make it chaotic if they chose.

The second principle, “Security technologies and operations must be as dynamic as the threats you face and the environments you are protecting,” isn’t just about technology; it is about the people, process, and tools we use to deal with the currently unknown. It is about building systems that allow users to act with appropriate information, in appropriate ways, to an environment that can become instantly dynamic when it has never been before.

“...Security technologies and operations must be as

dynamic as the threats they face and the environments

they are protecting.”

“...We have to find the opportunities to innovate our

defenses in ways that do not significantly impact our

businesses and users.”

2

4

AGILE SECURITY MANIFESTO #3 - NO SUCH THING AS A TRUSTED NETWORK OR DEVICEWhen haven’t we relied on some measure of trust in creating security systems and policies? Yet the number of controllable factors which establish trust are diminishing and becoming more and more transient.

• Who is a trusted user?

• What is a trusted network or device?

• How does a system establish and maintain the notion of trust?

These questions are harder to answer now more than ever because of explosive change occurring in the enterprise environment. Economic conditions have forced consolidation, driven outsourcing of traditionally internal services, commoditized our data, pushed new services into production, and increased our tolerance for risk to allow us to effectively compete. Lost in that process is the traditional review, the clear definition of trust, and the loyalty that once drove behavior. Trust implies some level of stability or consistency. It is time to face reality—that era is gone.

Trust as a static concept overlaying the dynamic enterprise is a security illusion. The world is moving too fast for that. Security must adapt to all the transient states that are part of enterprise IT environments today. The jury is in. Static security has failed too many times and organizations are looking to respond to threats and adapt security policies in the time frames that actually deliver a defense. We now have to ask, where are your applications, users, data, and access points? What devices are being used to access your data?

The organizations that thrive in the future will be dynamic across all of IT; why would anyone think that security will be exempt? This will push CISO/CIO leaders to innovate their approach beyond compliance checklists and accountant views of security. The critical question remains: How can an enterprise operate securely in this dynamic world, without the traditional trust model? The answer lies in security automation and visibility, allowing organizations to respond to change in the timeframes that “their” changes are happening versus days, weeks, or even later when it is too late. That means replacing the “trust” environment and its static reporting, operational blindness, and manual policy controls, with a “trust nothing” approach using realtime visibility and security automation.

The tired “trust” approach looks like this picture. All is beautiful until you let the snow melt, see what really is there, and then want to look in the other direction.

Agile Security Manifesto principle #3 states: There is no such thing as a trusted network or device. Moving forward organizations must adjust their past practices to the reality that nothing truly should be trusted—not devices, files, computers, users, or content. The only sustainable approach is a dynamic defense that is instrumented to your unique environment, always learning from the change and adapting security controls to be constantly relevant.

“...Economic conditions have forced consolidation,

driven outsourcing of traditionally internal

services, commoditized our data, pushed new

services into production, and increased our tolerance

for risk to allow us to effectively compete.”

3

5

AGILE SECURITY MANIFESTO #4 – OFFENSIVE RESEARCH HAS LIMITED IMMEDIATE VALUEZero-Day vulnerabilities are sexy, and hunting for them is even sexier. If you are heading to any security conference this year the big draws are always new exploit or new vulnerability talks. When a new Zero-Day vulnerability is discovered in a major software vendor’s product, even the mainstream media covers it. This builds the perception that Zero-Day vulnerabilities are a critical area of focus when laying out defensive technologies and play a major role in compromising networks. It also pushes a perception that security researchers and defenders should spend significant time searching for new Zero-Days that could be discovered by attackers and used to infiltrate protected networks.

While searching for, discovering and reporting new vulnerabilities seems to have some effect on the overall security of software, the real question is, does it provide a reasonable return on investment for any organization tasked with defending its, or other people’s networks? This discussion is core to Sourcefire’s Agile Security Manifesto principle #4: Attack research is useful but doesn’t solve security problems. Research should focus on innovative solutions to solve today’s security challenges.

Two recent studies, one published by iSEC Partners and the other by Microsoft, address head-on the real world impact of Zero-Day threats. For those who haven’t read these reports, the basic summary from the iSEC report is that the vast majority of attacks and compromises in 2010 were the result of 13 vulnerabilities for which patches are now available. And, since 2006 only 75 vulnerabilities have been widely used to compromise end users and enterprises. The Microsoft report even goes as far as stating “99 percent of exploits use common techniques such as social engineering and the targeting of unpatched, known vulnerabilities,” leaving only a 1% usage of Zero-Day vulnerabilities on the table. When we compare these statements to our own Sourcefire internal data we reach similar conclusions. This leads to the question of defensive investment: If 99% of the vulnerabilities that are used to compromise end users and enterprises fall into the non Zero-Day category shouldn’t that same level of investment be used to stop those threats? Asked another way: What is the better business investment, hunting for the bugs that might be used in 1% of the cases or investing in defensive technologies that more effectively deal with the 99%?

Looking at both the Microsoft report and the iSEC Partners report several commonalities jump out when reviewing the prevalence of unpatched vulnerabilities used to attack end users. Both reports highlight a high usage of Java vulnerabilities, including CVE-2010-0840, CVE-2009-3867, and CVE2008-5353 that all target the commonly installed Java JRE. Additionally, numerous attacks targeting Adobe Flash player, and Adobe PDF Reader where observed. If you’ve never done any work investigating these file types, the simple summary is that they are complex, compressed, and require substantial resources to effectively inspect for malicious content. When used in the wild they are obfuscated using encoders and other techniques that actively attempt to avoid defensive technologies.

With the attackers focusing on utilizing known unpatched vulnerabilities, and focusing their research dollars on making them more effective and harder to detect, shouldn’t defenders be focusing their dollars on improving defensive technologies so they more effectively

4

“...What is the better business investment,

hunting for the bugs that might be used in 1% of

the cases or investing in defensive technologies that more effectively deal with

the 99%?”

6

handle these types of armaments? Defenders should be focusing on finding better ways to deal with complex file types, locating better ways to dissect them for inspecting, and finding faster ways to quickly determine if something is malicious. While bug hunting for the next Zero-Day may protect a network against one new threat, it doesn’t produce any actionable information for defenders to use to effectively deal with the next set of application specific obfuscations and file type complexities. At the end of finding that one new bug, the investment is complete, and it only produced one small piece of actionable data—that the bug exists. It didn’t produce a better way to defend against the next one.

With the threat landscape as it is, we should focus our investments on finding the better way to defend against the next bug. A dollar for dollar investment in reverse engineering a file format trying to understand how it works, will pay out far higher dividends than spending those same dollars looking for one bug. Locating better ways to break files down, identify areas for obfuscation and evasion, and building agile defense technologies that allow defenders to quickly build detections for next threat has a much higher ROI than finding one individual bug. Stomping out one bug might help right now, but building a better defensive understanding and framework for dealing with complex bugs pays out every time a new bug shows up.

AGILE SECURITY MANIFESTO #5 - YOU CAN’T PROTECT WHAT YOU CAN’T SEESecurity administrators often say, “I wish someone could just show me what’s on my network.” This pain is at the heart of the problem with most security solutions today; they lack visibility into the network. This is why Agile Security Manifesto principle #5 is so important: Security without awareness is not security. You cannot protect what you cannot see.

The need for visibility in network security is centered around the cornerstone of network security—accuracy. Blocking valid traffic is more than just an inconvenience in networking; it can lead to lost revenue, decreased productivity and, in some very real occurrences, job loss. This is the reason that many networks deploy security in an alert-only capacity. But alerting to too many possible security breaches reduces security effectiveness as well. The amount of

event data presented to administrators for review can quickly overwhelm reviewers who will eventually choose to ignore at least large portions of event data in favor of less mind-numbing and menial tasks.

A newer challenge to security solutions is the frequency of change occurring among network assets. Fueled by consumerization of technologies, application euphoria, virtual creep, and the dissection of security teams from other network teams, new devices appear and disappear from today’s networks without notification to security administrators. New devices bring new operating systems and applications, which in turn, bring new vulnerabilities to the network.

Security solutions today need visibility into not only network traffic, but the assets that make up the network.

Security solutions today need visibility into not only network traffic, but the assets that make up the network. This can occur in a number of ways, but whatever the method it must be automated due to the frequency of change discussed above. Attempting to manually keep an inventory of devices, operating systems, applications and vulnerabilities will fail

5

“...The need for visibility in network security is centered

around the cornerstone of network security—

accuracy.”

7

quickly in a network of any material size. Automated vulnerability scanners, asset tracking tools, or passive traffic monitoring to determine the network’s assets allows technology to do what technology does best—automating menial tasks.

Gathering information is the first step in any well designed, decision-making process. Only when we have ongoing visibility into the network’s devices, operating systems, applications, files and vulnerabilities, can we make informed decisions regarding whether traffic and files are valid or malicious. This visibility can also be used to reduce unnecessary alerting by correlating attacks to assets. For example, detecting attacks against resources that do not exist or are not vulnerable to that specific attack is irrelevant and can easily be eliminated from alert logs. Taken a step further, a thorough inventory of network assets can allow for automation of security policy. Here, a completely customized policy evolves as devices enter and exit the network.

The benefits of security with automated visibility are clear: reduced administrative workload, improved accuracy, a reduction in alert logs, and more accurate reporting for internal decisions and for compliance. The drawbacks of security without visibility are real and will keep security solutions at least one step behind the well-organized and well-educated hacking groups threatening networks today.

AGILE SECURITY MANIFESTO #6 - DYNAMIC IT ENVIRONMENTS NEED DYNAMIC INTELLIGENCEAs pointed out in principle #5 of the Agile Security Manifesto, gathering information is the first step in any well-designed decision-making process. Many pages of documentation and hours of classroom time have been dedicated to this subject. The challenge? Seldom is this sort of information-gathering and decision-making reapplied, let alone in the rapid and infinitely repeating fashion that today’s threat landscape demands.

The sixth principle of the Sourcefire Agile Security Manifesto is “Intelligence Accelerates Security Effectiveness. Static Intelligence is of Little Value in Todays Dynamic IT and Threat Environments.” This may seem like a mouthful, but in fact it’s a pretty simple concept, albeit one that is often overlooked.

It doesn’t matter if you designed and implemented the world’s greatest birdfeeder. If you are not constantly monitoring for the presence of squirrels and keeping a constant eye on the level of feed available, are you really doing your job? The problem here is, in the time it has taken you to read this reference back to the birdfeeder analogy, your infrastructure has changed in some way.

What we are defending changes all the time. How we defend it must change, just as fast.

Understanding exactly what makes up our environments and knowing exactly when and what changes is intelligence; intelligence is the single largest ingredient in accelerating security effectiveness. In fact, we could easily argue that “static intelligence” is an oxymoron, referring to a rapidly decaying situational snapshot. It’s of little use to anyone taking security seriously.

Serious practitioners need to be able to apply security intelligence to the seemingly insurmountable amount of data being collected, using it as a filter in the distillation and retrieval of what is contextually relevant to that environment. Armed with this clear and concise picture, we can adapt our defenses and act on the data appropriately.

“...Only when we have ongoing visibility into the

network’s devices, operating systems, applications, files and vulnerabilities, can we make informed decisions regarding whether traffic

and files are valid or malicious.”

6

8

Security isn’t easy, and “set it and forget it” simply doesn’t apply. Commitment and vigilance is essential for continued success. The problem is that there is no finish line, just another chance to see what’s out there, learn the threats, adapt our defenses and act. During this cyclical process we need to ensure we have all the information we need to be effective, and understand that what we know now will be different by the end of this sentence.

AGILE SECURITY MANIFESTO #7 - BEWARE OF THE BLACK BOXMany security products come packaged with an appealing and deceptively simple claim: you don’t have to spend much time understanding your organization’s security problems—these products take care of everything for you. There’s seemingly no learning curve, no administration effort—all the bad traffic is blocked while all the good traffic is allowed to pass. How do you know that the systems are doing their job? The message from these vendors is “trust us.”

These products are “black boxes”—systems in which you can only see the inputs and outputs—the inner

workings are not visible. Black box systems are closed to inspection, closed to detailed modification, and closed to most interoperability.

In some industries, opacity doesn’t matter as much. Understanding the detailed inner workings of a washing machine is not critical to washing clothes—unwashed clothes and detergent go in; washed clothes come out. If the inputs and outputs of a system are well understood, it’s not absolutely necessary to understand its inner workings in order to determine whether it’s effective.

But in security, the inputs are not well understood. Security administrators don’t know every attack that could infect their files and traverse their networks; they don’t know every vulnerability in their systems. On their own, they have little idea which attacks might have succeeded in spite of their security products.

Because of this lack of knowledge, it’s easy for a black box vendor to deceive the end user. Black box vendors can assert nearly anything they want to about the extent of their protection, because it is unverifiable. Vendors can claim coverage for every vulnerability but in reality detect only a few exploits or nothing at all. Some black box solutions are the security equivalent of patent medicine—dubious remedies, supported by pseudoscientific evidence, with exaggerated marketing. Like a “magical elixir” salesperson might claim cures for cancer, arthritis, and sore throat, black box vendors give unrealistic hope to those who are less informed about security.

Skeptical security administrators turn to third-party testing organizations, which test systems with particular attack sets. The results can be informative, but some vendors “write to the test”, adapting their solutions to block the narrow sets of attacks tested by particular tools while ignoring the far larger threat space.

But a solution is available: the open security architecture. Security engines can be made transparent so that their claims can be inspected. With a community of security users and researchers inspecting the detection code, false detection claims will be called out. Coverage will be verified and broadened by the community. Sourcefire’s Next-Generation IPS and antivirus engines, Snort® and ClamAV®, are open and freely inspectable, along with the rules used to perform their detection. Many other vendors reuse them in their security products. The community can directly verify our detection and coverage for any attack.

“...If you are not constantly monitoring for the presence of squirrels and keeping a

constant eye on the level of feed available, are you really

doing your job?”

7

9

Open architectures also mean interoperability and reuse. Many other vendors’ products interoperate with ours through the use of the open eStreamer, Remediation, or Host Input APIs. The Snort rules language is the standard IPS language, created by Sourcefire and used throughout industry, government, and education.

Embracing openness requires moving up the maturity curve and trusting a process that is open to scrutiny. Which leads to principle #7 of Sourcefire’s Agile Security Manifesto: Beware of the black box. It is closed and hidden. Any system that does not give you full visibility into how it works should be suspect.

AGILE SECURITY MANIFESTO #8 - EVERY ENVIRONMENT IS UNIQUE; ADAPT DEFENSES QUICKLYThe eighth principle of the Sourcefire Agile Security Manifesto is: Every environment is unique. You must be able to adapt your defenses to fit your needs...and do so quickly.

We must make one important point up front right now: No two operational networks are the same, and they never will be.

We have worked with organizations for many years to help define achievable network security goals and design solutions that help them get there. At the start of the process we go through, it’s common to hear statements from the network team along the lines of, “We’ve got a standard n-tier network” or, “It’s just a normal client environment.” We must make one important point up front right now: No two operational networks are the same, and they never will be.

This is such an important fact that we’re continually surprised that people choose to ignore it. It’s also vital to understand that, from a security standpoint, a network barely even resembles itself a few months down the line. New systems, new software, new users, new vulnerabilities, new attackers, and new patches create a constant state of flux. This leads to a security challenge that continually evolves and is out of joint with the project-focused delivery of security we frequently see today. It is impossible to deliver ongoing security by implementing a short-term project; it is critical that we all understand that the goal posts move continuously.

So, with it understood that every environment is unique and always changing, we are left in a situation that no off-the-shelf security technology will match an organization’s specific

requirements. Sure there could be some overlap, but never a perfect fit. The ability to tune a security device to address unique needs is vital, and the ability for the device to configure itself is ideal to lower the ongoing efforts of managing security as things change.

Sourcefire has invested a large amount of development effort in creating solutions that address this challenge. Snort is arguably the most flexible and configurable security engine available. When linked with the visibility delivered by Sourefire awareness and automation technologies security teams can get a long way towards this goal with minimal effort.

Failure to tune a security system to a business’s needs at the time of installation leads to a suboptimal or failed deployment. Failure to continually adjust its configuration as the situation changes not only makes protection go stale, but provides us with a false sense of security.

“...How do you know that the systems are doing their job?

The message from these vendors is ‘trust us.’”

8

10

We must adapt security technologies to match the current environment they protect. In fact, if you are still forced to configure things manually and can’t leverage automation to do this for you, stop reading this now and go get started.

AGILE SECURITY MANIFESTO #9 - SECURITY IS NOT AN AGGREGATION OF POLICIES OR CHECKBOXES“I’m secure; I’ve got a firewall and an endpoint suite deployed.” That is the answer that many business owners give in the response to the question: Are you secure? It is a predictable answer across vertical industries following a compliance check list: Firewall? Check. Endpoint protection? Check. IPS? Check. SIEM? Check. GRC process? Check. Agile Security isn’t just checking all of these functional boxes nor is it implementing these individual capabilities. It’s a holistic, strategic approach to dynamic, flexible protection.

Enterprises today are working with antiquated processes, complex outsourcing relationships, as well as siloed decision, planning and buying structures. The result of this mix is a system more suited to telling leadership that a process or policy didn’t screw up the checkboxes rather than actually keeping the organization secure from attack. Today’s security posture is too preoccupied with minimizing change at the expense of real-time deployment of countermeasures. The benchmarks for security success are all focused on yesterday’s problems.

Before you think this is just another ‘glass-is-half-empty’ view of security today, consider the successes adversaries are having targeting highly controlled systems like satellites and military drone aircraft. We can no longer argue that the so-called state-of-the-art security is good enough. However, the world today is even more fundamentally challenged.

The real challenge springs from the belief that an ever-expanding and complicated set of policies evolving on their own functional paths with the “glue” of compliance and event management integrations will lead to better security. The reality is that enterprises can make all of these investments in controls and still succumb to a targeted threat despite their many policies. The adversary is well-versed in the tactics of enterprises and their propensity towards the status quo.

Organizations today are struggling to reduce risk and maximize protection. They have a firewall access policy, a Web Filtering policy, a DLP policy, a system/endpoint policy, etc. All of these policies help to reduce the surface area for potential attacks, but they don’t stop attacks. The bad guys will find a way to get around policy controls (or, perhaps, already have!).

Today’s attackers are like ants—no matter what you do, they will find a way in.

Enterprises and the security industry together need to adopt an agile frame of Enterprises and the security industry together need to adopt an agile frame of mind. Security is not a firewall; it is not policy; it is not “checking the box.” It is not one thing and can’t be made to be one thing. It’s a suite of coordinated capabilities that are leveraged to minimize risk and maximize protection while remaining responsive to the dynamic environment they serve. Sourcefire has been focused on a holistic, agile approach to security for many years. By delivering the world’s most flexible detection engine paired with innovations in awareness

“..Sourcefire has invested a large amount of development

effort in creating solutions that address this challenge. Snort is arguably the most flexible and configurable

security engine available.”

9

11

technologies and centralized management Sourcefire security solutions let you see, in real time, beyond mere policies and understand and adapt to what is truly going on in the real world.

Principle #9 of the Sourcefire Agile Security Manifesto challenges us to ask: How do we respond to changes? Are we relying only on policies to keep the ants out? How do we know that we are really minimizing risk and maximizing protection beyond our policies?

AGILE SECURITY MANIFESTO #10 - SECURITY IS A ‘BIG DATA’ PROBLEM“Big Data” is becoming one of the hottest topics in information technology. That trend has been precipitated by a number of factors:

• Storage costs are getting cheaper each year, which has made it easy for companies to capture terabytes (and sometimes even petabytes) of data related to their customers, suppliers, and operations. For example, on social networking sites like Facebook, users have shared 30+ billion pieces of content.

• A spate of technologies have been introduced in the last few years to help both manage and analyze large data sets; many of these technologies are open source, which has lead to their increased adoption and proliferation. These technologies are designed to overcome the limitations of traditional database systems that can potentially buckle under the weight of a tremendous load of data.

Nonetheless, being able to process this data is a tremendous business opportunity. For example, McKinsey published a comprehensive report detailing how sectors such as health care, retail, and manufacturing can benefit from big data technologies. For example, the US health care industry could potentially save $300 billion and government administration in Western Europe could save $150 billion in operational efficiencies by applying big data technologies to their operations.

The IT security industry as a whole also needs to utilize big data technologies. Defending a network requires the analysis of large amounts of data:

• Network and security devices generate continuously growing amounts of log and event data that contain insights about potentially malicious activity. Hard drive sizes continue to grow at exponential rates while price remains the same, which means that more of this data is being stored.

• The number of unique threats is growing each day. Several hundred million unique malware variants are seen each year and the vast majority of these are seen only once.

The growth of available security-related data is far outpacing the number of security analysts with the requisite skills to analyze it (not to mention the resourcing constraints a security vendor may face). As a result, security analysts are “drowning in data.” There is simply no way to examine this much data through manual methods.

We are seeing concrete evidence of this trend. For example, according to the latest Verizon data breach report, organizations used their own event monitoring or log analysis tools only 6% of the time to discover that they had been compromised. The report states: “Many smaller organizations do not have the awareness, aptitude, funding, or technical support to [use these tools] with the sophistication of the threats they face… even large businesses seem to have a difficult time utilizing their investments for significant return.”

“...Agile Security isn’t just checking all of these functional boxes nor is it implementing these individual capabilities. It’s a holistic, strategic approach to dynamic, flexible protection.”

10

12

Which leads us to principle #9 of the Agile Security Manifesto: Security is a “Big Data” problem. The security industry, as a whole, needs automated tools that can analyze data (including data generated by other tools) and provide actionable intelligence on the state of threats to their customers’ information assets.

Fortunately, this demand for analyzing large security-related datasets has been met with a supply of new readily available technologies that address these issues. For example, Hadoop, an open source implementation of the Map Reduce framework for processing massive amounts of data has been utilized in numerous industries such as social-media analysis and targeted marketing. More recently, security was mentioned as a “killer app” for Hadoop because it can use a “divide and conquer” strategy to automatically process the growing amount of security data in an enterprise.

At the same time, it is important to keep in mind that Hadoop is only a tool and not a complete solution in and of itself. In general, multiple tools and vendors are starting to emerge to form an ecosystem. It is our hope that the IT security industry can contribute to forming a more mature solution for security analysts to deal with their “data deluge.” Sourcefire is focusing resources to this end.

AGILE SECURITY MANIFESTO #11 - SECURITY IS A PEOPLE PROBLEMThe eleventh principle in the Agile Security Manifesto is “Security is a people problem and the technologies are tools that are made to enhance the abilities of people to secure their environment.”

This principle is so obvious to everyone that it is often forgotten. Why is it that security is a people problem? Is the people problem a result of greed? Laziness? Ignorance? Malice? It likely isn’t any of these specifically. Sure, greed, malice, ignorance, laziness, subterfuge, etc., have an impact and influence on any given incident, but none of them are generally the cause of the problems we face; people and how we interact with them are the fundamental catalyst. Most often, the overriding cause is that people just want to do their job and “security” stops them. Security practitioners know this all too well, they don’t like it but have little in the way of available tools to help them see beyond the trees. Everyone can relate to it, too; everyone has experienced security as a roadblock. We have seemingly forgotten that the people problem in security cannot be solved with technology alone.

Unfortunately a technology-centric approach exacerbates the security problem, not helps solve it. Instead of educating users on safe habits, enabling them to make good decisions and empowering them to seek timely assistance when they suspect something is wrong, security teams have imposed technological solutions in the hope that they will make the problem go away. We ignore our best weapons in this fight, and focus most of our efforts on stacked point solutions. When a user thinks their computer is behaving strangely, the security team should be the first place they think to call for a quick assessment. We should be deploying solutions that enable our users to do business better, faster, and, with fewer restrictions. We should be using the technology to back them up, not hinder them. If a solution isn’t agile enough to support this mode of operation it might as well be a lead weight on your profits.

Here is a typical example.. A sales employee has had issues with a company computer, knew it was a virus (indicated by the endless browser pops), and chose to defer requesting assistance because it would “waste” a day while the computer was being fixed. The sales

“...the US health care industry could potentially

save $300 billion and government administration in Western Europe could save

$150 billion in operational efficiencies by applying big data technologies to

their operations.”

11

13

employee worked with an infected system for N+ days until it was a more conducive time in the sales cycle to be without a computer and “out of commission”.

The result is that people use personal systems, personal email accounts, USB drives, write a CD, print and snail mail documents, and outright disregard and circumvent corporate policy to “get their job done.” They feel fully justified in doing so because they believe they are acting in a necessary and justified manner to achieve what they are paid to do. The net result is that they, and us by extension, have been locked into a repeating cycle of infection and insecurity. While they can get IT to help them “fix” their corporate computing resources, they have no help in fixing the personal resources they use to circumvent the real or perceived corporate security failure. The technologies employed were not enabling, effective, or agile enough to help them make quota.

The technology intended to help solve the security problem is in fact preventing us from understanding the scope and impact, hides the path to resolution, and forces our best assets into insecure modes of operation. The consumerization of IT has been in effect for over a decade, just not in a highly visible way, created out of desperation by employees just to get their job done.

A similar trend is emerging with cloud computing. Rather than engaging early and producing workable solutions with agile technologies that can adapt to the changes in deployment models, the trend seems to be to attempt to slow the adoption of these new models while they are studied and forced into existing operational contexts. Care to guess what the results will likely be?

People are complex creatures, each having different motivations and greatly varied levels of understanding, generally wanting to do good, striving to be good corporate citizens, and only in need of some help by pointing them in the right direction. Agile Security solutions that can adapt to the constant change our people introduce, enable them to do more/better/faster in a more secure manner than they did before, and do it in a way that the user can embrace are about the only hope we have of advancing the art of security as a whole. To solve the security problem we have to first address the people problem and then introduce technologies that help them achieve their goals in a more secure, non-intrusive, and efficient way.

AGILE SECURITY MANIFESTO #12 - SECURITY MUST BE AN ENABLERWhy is it that security in an organization is so often viewed as a roadblock or hassle standing in the way of business? Security professionals ask this question all the time. We complain that we are always the last one to the table when planning new projects and often find ourselves fighting for some unattainable balance between operational functionality and security concerns.

Indeed, training “the business” on the importance of security is essential, but security professionals must also work to understand the business needs of the organization and help enable its success. That brings us to the twelfth and final principle of our Agile Security Manifesto: Security must be an enabler. Organizational agility must be met with security agility to maximize data integrity, asset security, and a pristine reputation.

Over the previous 11 installments of the Agile Security Manifesto, we have talked in depth about our definition of Agile Security, but as security professionals how often do we

“...organizations used their own event monitoring or log analysis tools only 6% of the

time to discover that they had been compromised.”

12“...Most often, the overriding

cause is that people just want to do their job and “security” stops them.”

14

examine what it means to have an agile business organization? More importantly how can we work to enable the agility of our business organization while continuing to ensure its security posture?

...an agile enterprise is “one that is not easily damaged and broken by unexpected and unpredictable changes and events....“Agility is not just about speed of response – it is

about rapid adaptation.”

- Paul Kidd

These definitions sound a little scary. How can we build security practices around business practices that can and will change, over and over? Clearly, we will need to come to some sort of compromise, some bit of restriction on what can change and how dramatically. Throw up the roadblock! Sadly, this is the typical approach.

Very few companies or organizations sell security. The focus of these organizations is on their core offering, whether that is services, information, or the world’s best mousetraps. To remain relevant, organizations must remain agile. As security professionals we must learn our respective business processes, and look at the way that our security processes can enable a company’s success while still protecting its data, assets and image.

Not too awfully long ago, it was generally accepted that to have a secure system one would need to disconnect it from any type of network. Clearly that’s not a practical approach, and as the business world has become more and more dependent on network-based services, the security community has had to adapt.

Another example is remote access. Early on, remote access was typically restricted to IT personnel, giving them the ability to “dial in” and take care of any issue that may arise. However, the business side saw an opportunity for productivity gains and the corporate VPN was opened to the rest of the organization.

Let’s face it, security is seen by the business as a cost center. In an effort to combat that we often hear the stories of gloom and doom: “It may seem like a lot now, but consider what it will cost when XYZ happens.” This approach just continues to add to animosity and disconnect between business and security.

Imagine instead, taking the time to understand the business drivers of the company and mapping value provided by good security, not just avoiding the “cost” of worst-case scenarios.

We need to avoid the boogie man stories, and focus on how Agile Security® can help enable agile business.

“...When a user thinks their computer is behaving strangely, the security team

should be the first place they think to call for a quick

assessment. We should be deploying solutions that

enable our users to do business better, faster, and,

with fewer restrictions.”

“...Most of today’s security approaches simply

can’t keep up with the continuous, rapid change

in our IT environments and threats we face. These

approaches were designed for a different time when

environments were stable and slow to change.”

15

CONCLUSION2011 was one of the most damaging years in terms of security breaches. Information for hundreds of millions of individuals may have been compromised. Most of today’s security approaches simply can’t keep up with the continuous, rapid change in our IT environments and threats we face. These approaches were designed for a different time when environments were stable and slow to change.

The Sourcefire Agile Security Manifesto was developed to help provide a guidepost for organizations and the security industry as we wrestle with the unprecedented security challenges before us. These challenges are surmountable but will take a new approach, one that is as dynamic as the real world it protects and the attackers it defends against. These 12 principles form the foundation for a new way of thinking and addressing security, not only protecting organizations but helping enable them to succeed in today’s increasingly competitive climate.

Authors: Jason Brvenik, Steve Kane, Jason Lamar, Dr. Zulfikar Ramzan, Martin Roesch, Marc Solomon, Leon Ward

Sourcefire, the Sourcefire logo, Snort, the Snort and Pig logo, Agile Security and the Agile Security logo, ClamAV, FireAMP, FirePOWER, FireSIGHT and certain other trademarks and logos are trademarks or registered trademarks of Sourcefire, Inc. in the United States and other countries. Other company, product and service names may be trademarks or service marks of others.

7.12 | REV1