What's Your Security Epiphany?

I've recently had an epiphany on information security in the corporate world. Traditionally, we have all heard about the conflicts between "Security" best practices and:

• Regulatory Compliance
• Privacy Laws
• Business Operations

But, alas, there are conflicts between different views of "Security" as a protective measure:

• The FBI model: This is the traditional model of information security whereby all our security certifications (CISSP, CISA, CISM, Security+, et al) are based. This paradigm of information security is to ensure all parties, internal and external, are compliant to all regulatory requirements and/or using industry-accepted standard practices. This model is a purist view of security, focusing on all parties behaving properly; and it plays no favorites. 

• The NSA ideology: This model is a more intelligence focused approach to security. This model uses various means to identify internal and external threats to an operational organization. This threat awareness allows organizations to adjust their operations for avoiding and mitigating risks; however, this does not guarantee that an organization will take any actions or make any changes to mature their security program.

• The US Secret Service Approach: This model is an entirely different perspective on protection. In this model, the only focus is to ensure the business continues to operate, regardless of whether the operations themselves are secure (or even legal). These types of organizations view themselves as "too big to fail" (to use a recent cliche). In short, this model is a reference to the undeniable dedication of the USSS presidential bodyguards.

Having been a consultant for ~20 years, I've traditionally attributed differences of my clients' Risk and Security Management to every organization's unique culture. And my approach has been to provide the "Do What's Right" model through the use of tools such as security awareness training, vulnerability management, and policy/procedure creation.

With this new perspective on the various security cultures, I've learned to recognize the underlying motivational models of an organization's security program and adjust the focus to what can be matured versus what cannot be affected.

My goal has and always will be to focus on the betterment of an organization's security behaviors. Now I just know what areas to avoid.

What's your Security Epiphany?

Meaningless Risk Metrics

There are so many articles written on creating actionable metrics, key risk indicators, risk predictors and other forms of meaningful metrics that I decided to take the opposite approach: Let’s look at meaningless metrics, areas where we can and should pare down. We’ll draw some creative license in comparing security metrics through the designs of an automobile.

·         Don’t measure in irrelevant units: At what point in the advancement of the automobile did we need to know the numeric level of the volume? IMHO, one should just adjust the volume as determined by their hearing, not a visual cue.

·         Don’t oversimplify important items: I miss the days of knowing my oil pressure and alternator performance. It allowed me to know when things were about to break, allowing me to be proactive in maintenance. In today’s world, we have these dummy lights to let us know the obvious – something has already failed.

·         Don’t assume users understand relationships between metrics: Thank goodness cars still have the tachometer (it’s the big one left of the speedometer). And why is that important? Because knowing what the minimum, maximum and most efficient RPMs for a given speed – or gear for those who still favor a manual transmission – helps the driver operate the automobile at its peak performance.

·         Don’t distract users from their main responsibilities: I deplore techie-based user interfaces where they’re not needed. Anything that requires the driver to look away from the road and focus on an LCD screen is just dangerous, plain and simple. There’s a reason that older cars had two knobs and 5 buttons for the radio, and a slide lever for the heat and AC– so the driver could use their tactile senses to control those features while remaining focused …  on driving.

·         Stick to the point: When an automobile has advanced so far that there are more controls for non-driving than driving, something is wrong. In the end, a vehicle is only meant to safely get a user from point A to point B; everything else is meaningless.

To comprehend the performance of a vehicle is to understand the engine, drive-train and safety features. To sell the allure of the vehicle is to assume the user already knows (or is simply not interested in) the basics and instead deluge them in clever (but meaningless) features.

What's your opinion?

Protection Strategies - Part 4/3

“Look at what is built around you”

Ok, I thought it would stop at three parts, but there is always more to learn about information security from the outside world; and in my case the world of emergency services.

This continuing series of blog posts draw on the parallels between firefighter knowledge and security awareness. When a first responder initially arrives at a fire scene, they perform a situational assessment which includes the environmental factors (weather conditions), resource availability (water supplies), and building construction type. Today’s column focuses on the latter, knowing how things around you are built.

With building construction, there are five basic construction types[i] to be aware of. As with software applications and networks, there are several parallels between these two worlds.

1. The first two types of building construction apply to most commercial buildings. They are “over-built” in the sense that they have some generic (dead-load and live-load) requirements, but the internals can be reconfigured for various types of work. The three remaining types are mostly residential, meaning they are “purpose-built” structures.  
2. Also, within these two main classifications are two styles of construction, “traditional” which employs older methods of post/beam construction, and “lightweight” methods which use computer-aided design (CAD) models to define the minimum effort needed to support the building requirements. Good examples of this are “truss-roof” structures for commercial buildings and “manufactured I-beams” for residential buildings.

Studies have been done[ii] showing that the structural integrity of a building on fire has gone from several hours down to 20 minutes, so the window of opportunity to keep the first responder safe and save the building is greatly decreased.

Similarly, as more and more applications are built to narrow specifications using current Agile development methodologies, their resiliency for handling problems or other methods of discourse (that hackers may employ) is also reduced.

Unfortunately, for both the firefighter and information security personnel, there are few (if any) signs that what your protecting is resilient, or just a house of cards.

There are two facets to this issue of “what is built around you”: development strategies (for contracted / custom-built applications) and vendor management (for purchased / off-the-shelf applications).

Development Strategies: I am not, in any form, endorsing one development methodology over another – i.e. Agile versus Waterfall – as both have their strengths and weaknesses; but I am pointing out that SDLC methods, like other tools, need to be used in the proper way with appropriate training. All businesses have different resources they can draw from. In my company, I lean towards agile development when I know the team of designers and developers are subject matter experts (SMEs) in the goals and features of the product being built. However, when contracting out development, I tend to use the waterfall method to define very specific requirements to be built in an outsourced environment.

Vendor Management: When looking at off-the-shelf applications, do your research in the blogs, forums, customer support and bug tracking portals. There is a plethora of information about the application (both good and bad) that can help you make an informed decision. For example, for large companies, a product such as SAP for order management or logistics may be a good fit; but for my company, it is over-built. For custom software vendors, review their internal development lifecycle and determine if they place enough emphasis on security, configurability as well as features.

Finally, no matter which road you choose to deploy an application to support your business, pre-plan for the day when everything goes wrong. Security is about knowing how to react “when” a fire occurs, not “if”.

---

[i] http://www.firefighternation.com/article/truck-co-operations/understanding-building-construction-types

[ii] http://faculty.sunydutchess.edu/walsh/videos/FIRE-STRUCTURAL/New%20construction%20dangers.wmv

Cloud Security: Rock, Paper, Scissors

When consulting with client companies on moving applications to the cloud, I ask some very simple questions:

1. What is the criteria for going to the cloud? 
2. What is the fail-over plan for your application?
3. What security controls are in place in those applications today?

The answer to #1 is never "security" (and "elasticity" is mentioned with reckless abandon but that's another topic altogether). The answer to #2 is almost always "the cloud" as if it had some magical powers beyond server re-balancing to understand when an application is behaving badly. (There are many techniques to accomplish application-level fail-over, but most require design within the application.) Finally, the third question is guaranteed to produce an air of puzzlement.  Many companies rely on the "hard outer shell" security provided by their infrastructure; legacy applications which have worked for the past 10 years are taboo for modification; projects undergoing Agile development tend to dismiss designing security (because it is easy to design incremental functionality but difficult to design incremental security); and as good as development teams are, implementing for standards such as the FTC "Red Flags" Rule is just not on their priority list.

This does not mean applications are not secure; only that the security chain relies on layers of mitigating controls inherent in the environment for which is was originally built. When moving applications to the cloud, project managers need to understand how applications and their data was protected, and ensure a cloud provider can meet similar requirements.

The Cloud Security Alliance has created guidelines that both cloud providers and clients should reference for security guidance. The National Institute of Standards and Technology (NIST) also has similar guidelines geared towards cloud usage by government agencies; but is really applicable to every company. Even with the robust resources like these, there still seems to be some major issues in ensuring security of applications in the cloud:

- A 2012 survey conducted by O+K Research found that 55% of those companies polled did not consider security aspects when migrating projects from physical to virtual environments and only 18% of European companies virtualizing are actively taking a role in securing this new environment.

- A study by the Ponemon Institute shows a large disparity between cloud providers and clients about who is responsible for security in a cloud implementation. The fact that across cloud providers there are differing levels of assumed security responsibilities, there is an inconsistency in implementation the CSA guidelines.

- Understanding the contractual details and legal ramifications on cloud migrations is always a challenge. For example, if your application uses specific types of encryption or holds personally identifiable data (PII) for residents of particular jurisdictions; then the application may not be hosted on, nor the data pass through, specific countries. Applying locality clauses to some cloud providers may increase costs and reduce the efficiencies of going to the cloud.

As a general rule, migrating to the cloud will not increase security; it may even expose security weaknesses. Do not play "Rock, Paper, Scissors" with your cloud migration.

Protection Strategies - Part 3/3

In Parts 1 and 2 of this series, I took some basic strategies of firefighting to produce parallel tactics within the information security realm. The focus on firefighting comes from 30 years as a volunteer firefighter and assistant instructor at the local fire training center, so I am intimate with the subject matter. In addition, the principles of fire operations fold neatly into the fields of physical protection and information security. Finally, as I suspect most of our readers are not firefighters; I hope to pique your interest into the details of the fire service. This segment will focus on what the fire service calls “PPE” – personal protective equipment – and how it can transfer to making good decisions in building out your organization’s information security program. There are three separate areas of PPE, which I will cover:

Full Coverage: This refers to ensuring the firefighter’s gear prevents any exposed skin. In many cases, separate pieces of gear overlap. However, finding the correct fit is important. Too little overlap can reduce protection, and too much overlap prevents mobility. When looking at endpoint security for your business, your workstations should have anti-virus, anti-malware and personal firewall applications installed. Even though there is overlap (i.e. Anti-Malware may trigger on some similar Trojans that A/V would catch, Anti-Malware may flag data exfiltration through known bad ports much as a personal firewall should). This overlap is good, since most A/V’s catch on average 80-90% of all known viruses[i]. However, having two A/V suites on each workstation would be too much overlap since they would chew up resources, step on eachother and probably still let through 5-10% of malware. Finding the right products that work together without sacrificing CPU resources is more trial-and-error than absolute science.

Layered Protection: A firefighter’s turnout gear (coat, bunker pants, gloves, et al) consists of specific layers of differing materials for protection each for specific purpose[ii]. In the information security realm, we use the term “layered protection” or “defense-in-depth”:

a.       Outer Shell: This is your first line of defense. It usually has multiple primary responsibilities – for firefighters it needs to be flame and puncture resistant. For businesses, this outer shell is your router/gateway/firewall. It prevents rogue access through unused ports and should defer many simple threats, such as Syn Flood attacks.

b.      Moisture Barrier: For firefighters, water on your body can be the cause of burns – steam burns. So our PPE has a moisture barrier to keep the water on the fire and off your body. In parallel, businesses need some type of intrusion prevention systems (IPS) to keep out the bad elements from your network.

c.       Thermal Liner: For many fires, it is simply the radiant heat that routinely rises over 700 degrees that can cause the most harm. This indirect threat is mitigated through the PPE thermal liner. The liner is specifically designed to protect a firefighter up to a certain level of safe operation (any hotter and the conditions can become fatal, so the liner needs to allow the firefighter to feel some heat and know when to leave). For an SMB, indirect threats, such as social engineering, are usually the source for large data breaches. Social engineering, like radiant heat, is unavoidable and mostly uncontrollable. The best that we can do as an organization is educate our employees on information security awareness and the cascading effects of social engineering. When someone in your organization is under the impression that they are being con’d, scammed, under pre-text or otherwise feel uncomfortable about a situation; they must know what to do and who to call in your organization for assistance.

The Right Tools: There are a myriad of tools available to the firefighter for almost any situation, but trying to carry them all results in an over-worked and under-performing individual. Knowledge of what essential tools are needed for each situation becomes intuitive for the firefighter. Similarly to your information security group or CIRT team, these folks should be seasoned professionals that know what tools are necessary when, and not carry everything but the kitchen sink. Overloading a data breach situation with too many tools can bring your business operations to a halt, and may even damage and evidence that could be gathered. If your organization does not have in-house expertise, then having an external firm on retainer is necessary. I suggest having a firm on retainer, because it is better to work with such teams before an incident (to understand their competence level), than to have to contract with a firm during a breach incident (and being unfamiliar about their competence).

To summarize, your organization should have the overlapping coverage, layered protection and the right resources to properly operate in today’s harsh technology environment.

---

[i] http://www.av-comparatives.org

[ii] http://www2.dupont.com/Personal_Protection/en_US/assets/downloads/nomex/FS%20eBrochure_6.29.pdf

Protection Strategies - Part 2/3

In Part I of this series, I explained how I take a strategy from another familiar setting and produce parallel tactics within the information security realm. Part II of this article will continue this trend by learning the strategies used in Safe Firefighter Operations.

In many ways, the fire department is like any organization: there is a known organization structure, and workers are assembled as teams, and these teams interoperate to accomplish the same goal. And as with most organizations, one team’s interpretation of objectives may differ from another. For example, every team is trying to extinguish a fire with its hose; but it becomes a life safety issue when the interior team is pushing the fire outward with their hose and the exterior team pushes the fire inward with their water stream.

Pre-planned team coordination and clear communications across the entire organization are necessary to prevent injury as well as further damage.  In Part I of this series we learned that emergency services of all kinds rely on the National Incident Management System (NIMS) for a structured approach to communication and decision making at the organizational level. However, to operate safely at the lowest levels of the operation, each team must learn safety “circles of responsibility”. These priorities are simple and effective, and have served me well in both firefighting as well as information security awareness:

• Protect Yourself: Every team member’s primary priority is to protect themselves. This aligns with Maslow’s hierarchy of needs. In emergency situations, one needs to ensure that the team can focus on the issue at hand. If any single individual becomes a victim; then the entire team itself is taken out of service to deal with that individual. In parallel, if your workstation becomes infected, then you and your entire team must stop work while security and support teams review all workstations in that network and mitigate the situation.
• Protect Your Team/Company: Knowing how the loss of a single individual resource can affect team operations, it becomes your responsibility to look out for other team members. If nobody in your team is the evangelist for data security, then it becomes your responsibility to be it. If there is someone already in that role, then you should ensure other team members are following the recommended practices and procedures.
• Protect Your Client: Even though this sounds counter-intuitive for fire rescue operations, it applies. Your client is helpless if your team is disabled, which can be caused by one individual misstep in the team. In emergency situations, first responders will always have taken care of their first two responsibilities (through pre-planning and training) even though it may look like they jump to this step. Similarly, your Cyber Incident Response Team (CIRT) – no matter how small – should have done the same pre-planning and training so their response to your data breach will go smoothly.

As your business operations grow and become more complex, it is imperative that these safety circles of responsibility propagate throughout the organization.