Everyone wants information security to be easy. Wouldn't it be nice if it were simple enough to fit snugly inside a fortune cookie? Well, although I don't try to promote such foolish nonsense, I do on occasion pass on readily digestible nuggets to reinforce security principles and get people thinking how security applies to their environment.

Common Sense
I think the key to fortune cookie advice is ‘common sense' in the context of security. It must be simple, succinct, and make sense to everyone, while conveying important security aspects.

Here is my Fortune Cookie advice for June:

A perfect security program does not make your environment invincible! It would be astronomically too expensive. The 'perfect' security program achieves the optimal balance of spending, loss prevented, and acceptable losses (residual loss).

Now if I can just figure out how to stuff these little cookies...

Am I contributing to the problem of over simplifying security? Or am I reaching out to those who might not take an inordinate amount of time necessary to understand the complexities and nuances of our industry? You decide and feel free to share your knowledge-nuggets.

Fortune Cookie Security Advice - May 2008

Measuring the value of information security programs is difficult and a problem for the entire industry. In the second of the three part series, Intel discusses a practical approach to determine value of information security initiatives. Intel security professionals Tim Casey, Enrique Herrera, and Matthew Rosenquist discussed the success of Intel’s security value methodology outlined in the Whitepaper - Measuring the Return on IT Security Investments

Listen to how Intel utilizes this strategy as one means to measure the value of security programs. The whitepaper is available for download.

The 30 minute discussion can be replayed here:

The last of the three part series, Future State of Security Measurement, will occur on Wednsday June 4th. Everyone is welcome to participate or just listen in. Details can be found here:
http://communities.intel.com/openport/blogs/it/2008/05/12/how-do-you-measure-something-that-doesnt-happen

Good security conversations benefit all involved. The more we share, discuss, and challenge each other, the more we advance our industry. Thankfully, I have the benefit of working closely with a brigade of information security professionals and we banter at every opportunity, for the sheer pleasure and insights. In that same spirit, we hosted our first Blog-Talk radio session. This was a general discussion of the problems of measuring security.

The 30 minute discussion can be replayed here
Two other internet chats are planned. Everyone is welcome to participate or just listen in. Details can be found here.

Up to this point I have covered Application inventory as a cost savings initiative followed by a discussion of Application inventory starts with a definition, and finally Application inventory, what do you capture?

Following the natural progression of:

• Why inventory
• Boundaries of what to capture
• What to capture
• How to capture

The "How to capture" is not a simple task completed in a week or two. For a company our size this task is still ongoing after fourteen months. And our progress shows us that we will need at least till the end of year to approach some semblance of sustainability. By sustainability I mean that the information, process and people will be in place to keep the data in a fresh state so that true data-based decisions can be made at near real-time.

Every day the clarity of our inventory gets sharper and sharper as we identify and pull in the data owners. The quality of the information becomes more focused as more of the profile is filled out. There are internal systems that are starting to rely on the data we have captured. That data is being transformed into true business information which has value and can be used to make the right decisions at the right time. At times, it still feels like an uphill battle. Each day we stand side-by-side with those who see the value and push on the back of our partners as we slowly progress up the hill.

Now knowing the definition and what data we want to capture we could have progressed in a multitude of ways:

• Distributed work-load, individual owners
• Focused work-load, our team owning (interviewing)
• Centralized gathering (combination of above, driving people to a single location)

We chose to adopt the creation of a simple to use, centrally located (Intranet Application), that stored the data we needed. As mentioned in the past, we did our analysis by looking at applications on our enterprise that already contained the types of data we were interested in. What we discovered was that none of them had the flexibility to store the additional information nor the development resources to alter their systems. This pushed us to obtain permission to build a new application.

At this point you may be saying, "You built an application to reduce the number of applications?" Sometimes it is necessary to do the wrong thing in order to do the right thing. It would have been too easy to drop a spreadsheet out there and start gathering information. Short-term this would have cost the least and potentially would have allowed us to get part of the way there. The issue is the long-term sustainability and trust that comes from a solution like that. We would have security concerns, updating collision as well as the reduced ability to share the data easily with other applications.

Yes, we built a new application, using two people, in four weeks. Since implementation started we have supported weekly releases while expanding the data being captured, the usability for customers (and consumers) as well as enabling the removal of the majority of those other systems with parallel capabilities. We have great internal hosting solutions and have been operating non-stop since December 2006.

Our goal is still to do the right thing and properly manage our inventory through reduction. We were instrumental in providing the information and process needed to remove over 500 applications (and associated hardware) from our environment since we started our process.

In my next entry I will talk about some future enhancements to get us through the next year and the further reduction in application inventory we are charged with. Perhaps its time to start looking at how our original analysis for "Low Hanging Fruit" was successful and now we find ourselves making hard decisions in order to continue refining our inventory.

Have you had similar issues at your company? Do you currently have this challenge before you? I'm curious to hear some of those challenges and potential solutions.

Every software project I have worked on always started with some form of conflict and complicated interactions. This usually resolved itself through the use of a definition regarding roles and responsibilities. That definition kept people on the same page and helped everyone to understand who was doing what.

Now depending on when you happened to look at my job title over the last 13 years, you may have seen one of the following:

• Software Engineer
• Application Developer
• Enterprise Application Developer
• Software Developer

This means only that I moved from one department to another, however, the physical tasks I employed were the same. My output may have had a different installer/wrapper/output, however, it was the same. I designed, developed, tested and deployed an application into our environment.

When it was time to define the characteristic (metadata) of an application, we needed to start with definitions. Not only what an "Application" is but what "Software" is and how (if) it differs from each other and from an "Operating System".

This is vitally important because no matter who you talk to, they will have a difference of opinion in this area. Let me give you an example that we are currently dealing with. We are implementing a CMDB (Change Management Database) for our Service and Support organization. As our application data is pumped into that solution we had to decide whether it is an application or software. The CMDB definitions basically stated that software was the core items used to build a hosting platform whereas an application is the code hosted on that platform. A very specific definition for their very specific implementation.

Our definition was much more simple.

If it's coded, if you develop it, it is a software application simply referred to as an "Application". This can be developed internally or purchased. An application is not an operating system.

That means that everything running on our environment, that is loaded on top of an operating system, is an application and needs to be inventories. That also means if it is a web-based solution, with software code, hosted within a web-hosting solution, however, it is still an application.

We did draw a very discreet line in that we did not want to inventory certain things. Those are items that are "configured" inside of other applications. Item such as:

• Web sites without dynamic content, hosted within a dynamic web solution such as Microsoft Sharepoint or created with Microsoft Frontpage or another WYSIWYG client.
• Templates configured for an application.
• Fileshare
• Hosting Platforms (configuration of hardware and application software)

To put forth some simple rules, that people can evaluate their "Application" before attempting to add it for evaluation, we came up wtih some simple rules. It has to meet all of these with a yes response.

• Installed on Intel (or contracted) hardware?
• Initially used by more than one person (or application) at Intel?
• Does this have (or has it ever had) a development/support team?
• Does this have (or has it ever had) a development/release process?

This minimizes the possibility that we inventory applications that are sitting in a box, not installed on the environment. It also means that items we paid for, installed, licensed and such, are included. Whether on a server or on a client, we need to know about them so that we can work towards the simplification of our inventory.

Next I will cover how we have gone about gathering this data. Some approaches work well while others don't. Additionally, before you start gathering data you must have a solid review, maintenance and data quality processes in place or the data will be of no use for future analysis.

Have you undergone a similiar process? Are you struggling with doing this inside your company? Have questions? Let us know.

With the old year grinding to a close and opportunities of a new year opening before us, it is a good time to take a moment and make some new year's information security resolutions. Some are good holdovers from last year and a few are new to the list. I think all are good practices to promote security and hopefully will keep a smile on my face throughout the year (no matter what cyber meltdown may occur).

1. Vigilance. Maintaining effective legacy security programs is critical. Loss of such capabilities opens the door to old, known, and well refined attacks
2. Embrace/Beware of disruptive technology. Double edged bleeding technology can be a blessing and a curse. It can reduce costs, increase efficiency, open markets, and change your way of thinking, but is also like walking into a darkened room in a horror movie. You never know what may jump out at you and in hindsight you may think "well that was painful". On the hot-list:
   • Virtualization technology in all its glory
   • Smart-phones and other PC OS/application based portable devices
   • Social media sites, tools, and accompanying behaviors
3. Careful with my PII. Our Personally Identifiable Information (PII) is more important than anyone can measure. I will handle mine with care, insure others do the same, and simply say ‘no' more often than not, when asked.
4. Don't be a fish. Just say no to phishing and spam. Filters are wonderful but a few will creep through. If it looks suspicious, it probably is. Don't be shy, even with the weird stuff sent by people you trust. Just pick up the phone and call them: "Hey Ralph, did you send me this executable attachment via email?" Is it not that tough.
5. Give an effort for disaster preparedness. Regular backups and encryption are my friends. Nothing huge mind you, but at least apply where it makes sense
6. Choose not to be a victim and let common sense prevail. Two types of victims exist: those with something of value, and those who are easy targets. Therefore, don't be an easy target and protect your valuables
7. Talk and share security. We are stronger as a team striving for security, than alone. The bad guys are working together; it is about time we do the same. Talk about security and share what works or doesn't. Don't be shy.

Not rocket science, but most of the great ideas rarely are. Feel free to chime in and be heard. What are your security resolutions for 2008?

To defeat cyber attacks, we must first understand their characteristics and how they come about. Deconstructing threats is a way of comprehending the factors which drive information security strategy. Without understanding the nature of attacks, an organization is destined to thrash about trying to effect change, only addressing symptoms and oblivious to the root causes of the problems.

In the Beginning
The most important aspect to comprehend is all malicious security threats and attacks begin with a person who has an objective. This represents the attacker, or sometimes referred to as the ‘Threat Agent'. Make no mistake, a virus is not the attacker. The author and implementer of the virus is the attacker. Eliminating a virus is a short term solution to the symptom of the problem, leaving the threat agent to find another method to achieve their objectives.

Threat agents are people and therefore driven by human nature. People compelled to expend energy manifesting in an attack on your organization have some desired outcome, a goal in mind. Their objective may be vague or precise, motivated by passion or logic, it may be inspired by emotional, intellectual, or economic needs. Their actions may target you directly or your organization may simply be caught in their sweeping net of activity. The permutations are mind boggling, especially when you take into account attackers include trusted persons intimately associated with the organization. Most importantly, they are thinking opponents who may plan, react, adapt, weigh options, and make decisions necessary to achieve their objective. Security success is heavily dependant on never losing sight of this key perspective. Attacks and threat agents are irrevocably tied together.

Building a Model
So if you have an attacker and their objective, the only component missing is the means for this person to achieve their goal. This path is the method. In reality, it most likely is a number of methods which are evaluated and one or more eventually employed. The term ‘vulnerability' is a catch-all phrase attached to express these methods. The term itself is far too broad to be meaningful. Anything can be a ‘vulnerability', including a security control itself. If you have a deadbolt on your door and someone kicks it in, an expert may declare the deadbolt is the vulnerability. Somewhat absurd, which is why I personally dislike using the term. So don't expect to see that word much from here forward.

What do methods look like? It depends on the attacker, what opportunities are available to them, and their objectives. If an attacker is seeking personal satisfaction through ego gratification of power, they may decide to employ a Denial of Service attack to show they can affect a target network. An accounts payable employee may secretly use their legitimate access to issue checks to collaborators for their personal financial gain. Again, the possibilities and permutations are as vast and varying as the people involved.

Threat Model
This basic model is straightforward. A threat agent, willing to effort an attack, has an objective in mind and selects one or more methods to succeed. Once committed, they initiate their plans and the game begins. Defenders may put up obstacles, close possible methods and the attacker, if still motivated, will respond.

Defeating the Attack
The game continues until the attacker succeeds, the attacker is removed or demoralized, the methods are rendered ineffective, or the objective is removed. Removing the attacker is a good but very difficult prospect, usually involving some type of law enforcement. More often the attacker is demoralized by making the prospect of achieving their objective very costly, so they either give up or move to an easier target.

Prevention activities are heavily weighted toward closing the most likely methods. A good strategy, which scales across many different attackers, but the simple fact is an attacker only needs one winning method to triumph. Much of the efforts to close different paths to the objective are intended to make it progressively more difficult for attackers to succeed. Not every path or vulnerability (ugg, hate that word) must be eliminated, only the ones which the attackers are willing to effort. The more inconvenient and inhospitable the environment is for the attacker, the better it is for the defending organization.

Lastly, removing the objective from temptation makes an attack pointless. The famous bank robber Will Sutton purportedly replied to the question "why do you rob banks?" with "because that's where the money is". The same no-nonsense principle applies to information security. Take away the objective, and the very reason for the attack is undermined.

Understanding the characteristics of attacks is paramount to good security strategy. It helps clear the fog of effectiveness and provides a perspective on how attacks can be stopped in a coordinated manner.

Want to get serious about Information Security? It is time for a Defense in Depth strategy. Interlocking Prediction, Prevention, Detection, and Response capabilities is the key. As no single solution provides comprehensive security, the way to achieve optimal security bliss is to apply a Defense in Depth approach of complementing capabilities to protect your computing environment and the data within. This strategy is highly effective at providing security assurance, cost efficient, scalable to large organizations, adaptive to changing threats, and proven to work.

The concept is straightforward. Establish a system of capabilities and services which align to attackers, their objectives and the methods they are most likely to attempt. Couple this with an understanding they will succeed sometimes and embed the fact at every turn there exist a learning opportunity to improve the system.

Prediction:
Security threats are about opposition. These threat agents are living, breathing opponents who are creative, knowledgeable, motivated, and have personal objectives in mind. These agents utilize available methods and resources to achieve whatever goals they seek by leveraging vulnerabilities in people, computing systems, and communication networks. In total, this represents a massive potential target landscape to be protected, edge to edge. Good luck.

The reality is you can't protect against everything and everyone. It is too cost prohibitive and in most cases impossible anyways. Although the truly paranoid may disagree, not everyone is interested in attacking you and within the realm of possible attack methods; it is more than likely only a few would be employed. The "path of least resistance" rule applies here.

A common pitfall is to rely exclusively on vulnerability assessments to determine where to focus. Although vulnerability assessments are valuable, they are misleading if the only source for Prediction. Understanding your opponent is fundamentally different than being aware of the weaknesses inherent to your environment. The result will be expending effort on areas which will never be targeted for exploit. Consequently, fewer resources will be available for areas under siege.

The best security professionals understand the relationship between attacks and the environment they protect. They marshal their resources to intercept the most likely attack vectors for the greatest effect. Prediction is the first step in the efficient use of security resources. Knowing why your organization would be attacked, likely targets, and the ‘easy' ways which tantalize attackers, provides the insights necessary to prevent such incidents.

Prediction:
Security threats are about opposition. These threat agents are living, breathing opponents who are creative, knowledgeable, motivated, and have personal objectives in mind. These agents utilize available methods and resources to achieve whatever goals they seek by leveraging vulnerabilities in people, computing systems, and communication networks. In total, this represents a massive potential target landscape to be protected, edge to edge. Good luck.

The reality is you can't protect against everything and everyone. It is too cost prohibitive and in most cases impossible anyways. Although the truly paranoid may disagree, not everyone is interested in attacking you and within the realm of possible attack methods; it is more than likely only a few would be employed. The "path of least resistance" rule applies here.

A common pitfall is to rely exclusively on vulnerability assessments to determine where to focus. Although vulnerability assessments are valuable, they are misleading if the only source for Prediction. Understanding your opponent is fundamentally different than being aware of the weaknesses inherent to your environment. The result will be expending effort on areas which will never be targeted for exploit. Consequently, fewer resources will be available for areas under siege.

The best security professionals understand the relationship between attacks and the environment they protect. They marshal their resources to intercept the most likely attack vectors for the greatest effect. Prediction is the first step in the efficient use of security resources. Knowing why your organization would be attacked, likely targets, and the ‘easy' ways which tantalize attackers, provides the insights necessary to prevent such incidents.

Prevention:
This is where the magic happens. Preventing or deterring attacks is where everyone wants to be. Given the insights of Prediction, which includes incorporation of industry best-known-methods, you can put forth a front line of defense representing the bulk of your cost efficiency. The purpose is to render ineffective the most likely methods the attackers will employ and deny the attacker's their objectives.

Prevention can take many forms, both technical and behavioral. Here are some examples, but don't take this as a complete list or even a recommendation, as selecting the right prevention solutions is specific to the environment and organization. Policy, security awareness, web proxies, and email filters are examples intersecting people based attacks. Computing systems can be protected with anti-virus, system hardening, compartmentalization, authorization and authentication controls, host firewalls, and timely patching to name a few. Communication network attacks are prevented mostly with high speed automated technical solutions such as firewalls, proxies, as well as secure device configurations and a good network architecture plan.

At its best, a solid prevention plan will eliminate threat agent's easy attacks and protect those critical assets most sought by the attackers. Doing a good job here translates into the biggest bang for the security buck.

"Two types of victims exist: Those with something of value and those who are easy targets. Therefore, don't be an easy target and protect your valuables."

Detection and Monitoring: ( ...when the security drums fail - video)
Unfortunately, at some point a number of attacks will succeed. Although it is most efficient to deter or prevent attacks, ignoring those that do get through the front line defenses is ill advised. Security incidents and intruders must be promptly identified, cornered and squashed like bugs. The first step is the ability to rapidly ascertain when the Prevention defenses have been breached and track the actions of the buggers. Detection and monitoring capabilities sound the alarms and direct the Response resources to the source. Speed and accuracy is most important in detection. However, it must be designed to look in the right areas as it is cost prohibitive to watch everything. Again, Prediction can play a role in deciding what to watch as well as how to monitor.

Response & Recovery:
How an organization responds to successful attacks will have a great determination on what residual losses are finally realized. When an event occurs, having the right processes, people, tools, and capabilities in place to contain the security event is critical. Time is on the side of the attacker. The goal of the security professional is to eradicate the security problem and restore the environment to normal operations. This may range from minor efforts to catastrophic recovery. The earlier the Detection capabilities alert the organization, the easier it is to corral the issues and recover. The savviest attackers are stealthy. They want plenty of time working on achieving their objectives and they dig deep like an infected tick. The longer they have inside, the more damage they can cause and become progressively more difficult to eradicate.

Don't be caught without proper Response and Recovery capabilities. Inability to restore the organization to a safe and normal state, translates to hemorrhaging money, time, resources, productivity, and maybe worse.

Continuous Improvement:
Information security is a continuous process. Key learning's from every event can improve individual areas as well as feed the Prediction services, thus giving a better understanding for the next time around. Defense in Depth can successfully be managed centrally or in a distributive model, as long at the overall strategy remains intact and interactions drive continuous improvements.

If you are ready to take the Defense in Depth plunge, you will be rewarded. Interlocking your strategy in a coherent manner gives better insights to reach and maintain your optimal level of security.

The Problem of Measuring Information Security
Getting a Return on IT Security Investment