As audit season is finally over, (over 65% of all our assessments and audits happen in Q4) we finally have a chance to grab a cup of coffee and look back at a couple trends in 2011 that we think separate the best security teams from the worst.

First, we need to discuss how we measure the quality of a security team. At Savid, it is pretty simple. Since we perform ethical hacking to assess security programs at organizations, if we got access to something we shouldn’t have, it counts as an intrusion in our books.

Most reviews of security controls look at what went wrong because it’s harder to learn from the successes. So let’s get the major failures of 2011 out of the way and then let’s talk about what our best clients did to prevent us from breaking in. Overall, most of the security programs we assessed had application security issues. However, 2011 was the worst we have ever seen in terms of the depth and breadth of application security issues – even though the majority of the security programs we tested were in compliance with regulations such as HIPAA, PCI, and GLBA.

Ok, so with that out of the way, what did the best security teams do to prevent our ethical hackers from breaking in?  One Thing: Defense In Depth. 2011 was the first year where we saw significant advancements in defense in depth deployments among our clients. For example, we saw a noticeable increase in proper system hardening (using standards such as CIS and NIST) and reduction of excessive permissions that stopped our attacks cold.

Properly deploying defense in depth can be the distinction between a data breach requiring notification or a simple documented incident. The difference between the two for some organizations could be millions of dollars. Oh, and it also has a side effect of making most malware non-functional by preventing the malware from creating temporary files, accessing DLLs, etc. Remember, an attacker can’t exfiltrate data if the exfiltration tools won’t run!

So, how did the defense in depth stop our hacking? Most of the time we were able to get entry into a server or application but because of defense in depth we weren’t able to leverage that entry for any gain (such as privilege escalation, intellectual property, or personally identifiable information). For example, if we got access to an application via SQL injection, we weren’t able to execute any commands on the server because the SQL server was hardened to prevent usage of xp_cmd and the SQL service account had no local permissions on the box to do anything other than access the database files and folders. Another example is when we got access to a Linux system running a custom PHP login system via an upload vulnerable and a PHP Shell script. The hardening of Apache and the file system prevented our low privileged web server service account from reading local files, creating files, etc. Essentially, the account we got control of was useless and the attack vector wasted our time and effort.

Wasting an attacker’s time and effort is exactly what you as the defender want to do. Every minute an attacker is stalled or delayed is more time for your detective controls such as IDS/IPS, Logging, or even Tripwire like defenses to detect an attack. We recommend that every security program have a simple theme: If You Cannot Prevent It, Detect It. Leveraging defense in depth provides additional detection points along the attack path. Every time a low privileged user attempts to access the Accounting Share – detect it. Every time a server in your DMZ attempts to connect to a server in the internal network (which should be blocked by the firewall) detect it and respond to it. These are all indicators that the server is doing something it shouldn’t.

Our number one recommendation when deploying defense in depth with proper detection controls is the use of fake records – commonly called “honeytokens”. For example, if you have a public web application that has access to an internal database server through a firewall, place a fake record in the database using a randomly generated 30-64 character value. This record has no value and should never be accessed via normal web application use. If your firewall, web filter, or DLP system ever sees this traffic move across the network – something went wrong and you need to find out why.

Every year Verizon releases their Data Breach investigations Report and year after year they mention the same problem: The time between a breach occurring and detection of the breach is too long, sometimes it takes years! So this year, add some more defense in depth controls to your security program and watch how quickly it helps reduce the impact of a vulnerability.

Gartner, the largest IT research firm in the world, is predicting that 2012 will be the year that more than 50% of Global 1,000 companies store customer data in a public cloud – a 30% increase from 2011. Of course, these firms have compliance and regulatory concerns which should make you ask how are they putting potentially sensitive data into a public cloud? Sadly, the answer isn’t some amazing new technology it’s actually technology that was developed in Egypt circa 1900 BC – encryption.

Encryption As A Service (EaaS) or “cloud encryption” as it is commonly called is being used by more and more global firms to enable them to leverage large public cloud vendors such as SalesForce, Amazon, and even DropBox. Cloud encryption isn’t really new, it hit the security industry scene in 2008 but more vendors, lower prices, and simpler implementation capabilities has put it into the list of “technology to learn about” for most CIOs and CSOs. Let’s discuss how these cloud encryption services work.

First, there are multiple types of cloud encryption. Some vendors offer encryption for virtual machines that run at cloud providers such as Amazon’s EC2 or Rackspace. Other cloud encryption vendors provide application level encryption by being an API proxy. For example, services such as SalesForce and Google Apps instead of storing a credit card number in plaintext in a field at SalesForce.com, the encryption proxy at your company’s data center encrypts it first and SalesForce.com stores the encrypted value instead of the plaintext. Lastly, some cloud encryption vendors provide file based encryption where individual files are encrypted and the names encrypted instead of encrypting the actual storage.

Regardless of the cloud encryption approach, you might notice a trend. Cloud encryption technologies are really just “cloud” versions of the same technologies that have been in use at data centers worldwide such as Full-Disk Encryption, Database Encryption, and File Encryption. The difference is that these cloud encryption vendors solve one problem that plagues organizations – staying up to date with the data sources and destinations the encryption technology works with. No more having to rewrite an application because SalesForce changed their API, the cloud encryption vendor does that for you.

The majority of failed encryption deployments we analyze fail because of key management. This problem is still in cloud encryption and may even be worse depending on how many cloud vendors your organization uses; however, most cloud encryption solutions allow you to use your own keys and most allow you to use your own key management system.

So what’s stopping you from moving to the cloud if you can simply encrypt any sensitive data that will go in and out of the public cloud? Our research from over 500 security professionals within the US shows that while cloud encryption greatly decreases the risk of using cloud services it does not change the fact that most organizations don’t know what data needs to be encrypted or even where that sensitive data is! While not a requirement, those firms that implement data centric security find it much easier to move their data to the cloud so perhaps you can use that cloud project as a reason to move to data centric security.

Risk Management is essential to a proper security program yet many organizations struggle with implementing risk management. Savid advises companies around the world and are frequently asked what risks really matter. Should we be worried about a zero-day attack? What about all these mobile devices? Many CISOs get caught up in the risk management process and when push comes to shove they end up making a decision based on their gut instinct using the data to rationalize their decision.

This phenomenon actually has a psychological name – Confirmation Bias. Confirmation Bias is the tendency for people to favor information that confirms their preconceptions. Confirmation Bias is the reason why managers and executives will spend 30% of their budget on a project that no one else seems to think is important but gets pushed through anyway.

At Savid, we have been researching confirmation bias for over two years now and have identified a few key areas that most CISOs can tweak to reduce the chance of making gut decisions that more often than not don’t succeed. Let’s discuss the biggest one: Bad Metrics.

Most security organizations manage risk using metrics that don’t matter. The percentage of machines with high risk vulnerabilities, patch latency, or anti-virus metrics are important, don’t get us wrong, but they don’t help the CSO make decisions because most metrics simply provide data. Properly built metrics will provide the data in addition to answering a question. Let’s use an example to explain.

If we have 122 machines with more than 5 high risk vulnerabilities per machine what does that mean to the organization? The answer: who knows? There are many other questions that must be answered first before we can use this data to make a decision, such as were the 122 machines the entire environment or was I only able to scan 122 out of 3,244? Are the 5 high risk vulnerabilities all unique (meaning I have 610 separate risks) or are they the same problem appearing 122 times? While these questions are important, the ultimate question that is usually never answered is this: Is having 122 machines with more than 5 high risk vulnerabilities above my organization’s tolerance for risk?

And that is where confirmation bias jumps in. CISOs, executives, and decision makers might look at the data and start running around concerned that the 122 machines are a massive threat to the organization and we must fix the problem immediately or they might ignore it, and it all depends on the risk tolerance and the risk aversion of the person responsible for making decisions.

So how do you address bad metrics? First, never use a metric that does not have the following properly defined: Name, Category, How to Measure, Purpose/Decision to be made from the metric, baselines, Target Audience, and Reporting Frequency/Period. If you went through all the data your team collects today how many metrics would you keep if you actually assigned a Decision/Purpose to each one? Our research shows that you will end up with less than 15 but will keep some others around when deep diving is needed.

Each metric must have a baseline defined and not just a single baseline but areas. For example, if we take our example above, we should have a defined baseline for the minimum number of machines that must be scanned, the threshold for when this metric indicates an acceptable amount of risk (Green) such as less than 1 high risk per machine, when it is a moderate risk (Yellow) of more than 2 but less than 5 per machine, and an immediate risk when greater than 5 (Red).

While this example isn’t a perfect example that you can use in your environment today, it should illustrate the picture we want you to see – Metrics thresholds are not metrics, they are measurements and you cannot manage risk without decisions being linked to each metric.

Once you implement and define metrics appropriately, the chance of Confirmation Bias causing a problem is greatly reduced because the decision parameters are already laid out and decided within the metric itself – the CISO won’t have to make a gut decision on whether to address the problem or not, the organization has defined when the problem will be addressed based on the status of the metric.

We have all seen the graphs, three pies:  one marked aggressive, conservative, and moderate. Usually associated with 401K or IRA accounts, these graphs show an allocation of various assets in order to meet a specific return level given a certain amount of acceptable risk. You pick one and the company handles the reallocation and dirty work of making sure you never have more risk than you want.

Is your risk management program structured the same way? It should be.

Most risk management programs involve committee meetings, an excel file with many risks identified by a high, medium, or low, and the committee arguing over which one should be addressed. Besides the confirmation bias problems we discuss in our other article, most risk management programs don’t have goals. Think about those 401K accounts, you pick the conservative model because the goal you want is a return of 4% with very low risk. If you had a higher risk tolerance you could have selected the aggressive model which gives an 8% return with a much higher risk.

Your risk management program should be structured in a similar way. All of the risks in that excel file are there to help the organization understand their current risk exposure and how it compares to the risk tolerance for the organization. If there is a gap between the current risk exposure and the risk tolerance of the organization, that is an opportunity to introduce additional risk for additional gain. The problem is most organizations haven’t defined their risk tolerance and have defined metrics to determine if they are above or below that risk tolerance.

How do you implement this approach to risk management? It’s actually rather simple. Instead of looking at metrics and the individual risks to make decisions, take a step back. First, categorize the metrics into projects they apply to; if you can map these projects to business goals, even better. Next, for each project, have the owner of the project create a success state and failure state for the project. For example, if our critical apps are available for 98% or more of the time, the project is a success. Lastly, have them review their metrics, and answer a simple question: On a scale of 1 to 5, where 1 is unlikely and 5 is very likely, what is the likelihood the project will meet the success state?

Using qualitative, instead of quantitative, metrics on the likelihood of success is similar to what a mutual fund manager does. If the conservative portfolio you selected has stock, it becomes much riskier and the likelihood of meeting the 4% return has gone down, they will adjust the portfolio to meet the goal.

Risk management isn’t about eliminating risk, it is about managing risk to an acceptable level so that the business can innovate and grow. Our guess is, if you start adjusting your audit items based on the likelihood of meeting project outcomes instead of just their risk level you will have more items addressed, less meetings talking about why things need to be done, and will be able to start identifying opportunities where you can take additional risk because the organization is managing their current risk appropriately.

Image via CrunchBase

As the clouds continues to roll in, (Sorry, I had to…), we are learning of more attacks being successful against organizations such as Google, Facebook, and others. The latest is from a security researcher, Christian Heinrich, located in Australia. He reverse engineered the algorithm Facebook uses to access your personal photos. Since Facebook is a massively distributed application, items such as photos and larger files are placed into a content distribution network (CDN) such as that provided by Amazon, Akamai, and others in order to reduce the load on Facebook’s servers. The thing is, the CDNs don’t integrate into Facebook’s authentication framework since the CDN just stores files and serves them to anyone that requests the proper filename. Guess the filename of the private photos for a person on Facebook, send the request to the CDN, and you get the photo in return.

And that is what led to an arrest and charges for a privacy breach. During his presentation, Heinrich demonstrated this vulnerability at Flickr, Facebook, and MySpace. He demonstrated how we could access the private photos of his fellow researcher, Chris Gatford’s, wife. One example showed a picture of Chris Gatford’s wife and child. The Queensland Police responded to a complaint, although we don’t know who filed the complaint, about Heinrich’s breach of Chris Gatford’s wife’s privacy caused by the demonstration. The Police responded by arresting a reporter for the Sidney Morning Herald, who had interviewed Heinrich about his presentation, and seized the reporter’s iPad.

Is this really Facebook’s or Flickr’s problem or the CDN’s? It most definitely is the content producer’s problem. The CDN network could provide authentication and more advanced security controls but that lowers performance by 30% or more for each transaction.

Ah, the old security versus performance argument. That age old argument is why this little and perhaps unknown arrest in Australia affects your organization whether you are using a CDN or not. When the performance versus security argument comes up during your career, the focus must be on the data type being discussed. Usually, the data type(s) being discussed including different types of data that need to be enhanced for performance to increase. It is likely that as you dive in deeper, many of pieces of data will not be private or confidential, but if they are you must stick to your security guns and only allow authenticated and authorized access to that data. The other data you can push out and optimize all the organization wants.

Your argument back to IT or development about the perceived performance gains they believe they can achieve by optimizing the data is one of analysis. You must ask to analyze the estimated increase in performance of only allowing the non-confidential data to be accessed without security controls.  Meeting them halfway by only optimizing the non-confidential data results in them having to accept a 15% or 20% increase in performance, which may be less than what they were estimating, but it is better than no increase at all.

Related articles

• Journalist quizzed and iPad seized by police after reporting Facebook privacy bug (thenextweb.com)

A new video from Tony Czarnik, our Security Practice Manager!

This two part video series will discuss what application security is, how to identify application security flaws and how to build an application security program specific to your organization while reducing operational costs and staff requirements.

Watch the Video >>

Image via Wikipedia

When companies come to me because they want to draft a security policy, the first question I ask them should be the most obvious: “Why?”

It may seem like a simple question, but more often than not it is met with confusion as if the answer was so obvious that it cannot be articulated. At other times, the answer is that they are simply compelled to have a security policy by law and regulations. But bandwagon mentality or compliance reasons will not generate a successful security policy. Starting with the “why” is the most important step when crafting a security policy, and the answer to “why?” comes from a risk assessment.

Risk assessment is an endeavor to find out why you need this policy and what it hopes to achieve. Risk assessment determines the magnitude of potential loss and the probability that the loss will occur. For security, this means classifying information into separate levels of sensitivity, then, discovering the possible risks, and the probability of those risks, that this information may be compromised.

It is not possible or sensible to protect all information, regardless of sensitivity, with the same maximum level of protection. And there is no cookie-cutter, one-size-fits-all approach to creating a security policy since every business has unique risks and places different values on different kinds of information. This is why an individual risk assessment must be performed. Once this has been determined, a security policy can be crafted based on protecting information based on its value and risk unique to that organization.

The problem is that too much policy work is driven by compliance rather than need. Without first identifying the need (the “why”) a security policy is destined to miss its mark and be nothing more than a symbol of intent rather than a useful procedure.

By relying simply on compliance to dominate a security policy, you may live up to laws and regulations but remain vulnerable. Compliance alone has not saved many companies from data breaches, including the credit card processor Heartland Payment Systems, who suffered an unauthorized disclosure of 100 million credit and debit card transactions while remaining compliant.

Security breaches and how attackers break in to networks and systems are difficult to explain and conceptualize because of all the moving parts involved in an attack. Data visualization of these complex attacks is effective because it shifts the balance between perception and cognition to take fuller advantage of the brain’s abilities. Seeing (i.e visual perception) which is handled by the visual cortex located in the rear of the brain, is extremely fast and efficient. We see immediately, with little effort. Thinking (i.e. cognition), which is handled primarily by the cerebral cortex in the front of the brain, is much slower and less efficient. The more we can gleam from a picture the more likely the oft quoted phrase “a picture is worth a thousand words” is true.

While there are only a couple of books on visualization of security events, most is focus on presenting security data such as facts and figured visually. The tide is changing though as we are seeing more people start to actual perform visualizations of attacks. These visualization convey much more data than a table ever could.

Ben Reardon, a fellow Honeynet project member, who created the visualization wrote on his company’s website that “with the increase in popularity of VoIP telephony, attacks are becoming more prevalent. The compromise of a VoIP system can cost the victim over $100,000 in real cash. For example, an Australian based company suffered $120,000 in toll fraud as a result of a VOIP compromise.”

Here’s a brief primer so you’ll know what’s actually going on:

• The purple bubbles to the left of the screen represent user accounts belonging to people who sign up for VOIP phone services like Skype.
• The tiny white and red bubbles are malicious scans from the hacker’s computer that are executed as a way of breaking into customer accounts to steal passwords.
• The green bubbles represent imposter data or in cyberspeak “honeypots”  that the server sends to intercept the scans and prevent them from compromising user’s accounts.

Visualizing a cyber attack on a VOIP server from Ben Reardon, Dataviz Australia on Vimeo.

Original Source for this Post

Image via Wikipedia

You don’t need a 6th sense to detect when a fellow IT security pro is engaged in a hot project, like implementing a defense in depth strategy, DLP tool or a PenTest project, when for 10 hours a day they can role play as a nefarious, ethical hacker. They spring out of bed without an alarm, their ipod rocks as they think of their project on the way to work, and usually work while others sleep. And as they sense the success of their project is in reach, there is a gleam in their eye like Melvin Purvis knowing Dillinger will be at the Biograph theatre that night. Yes, that’s you. The details are different, but you act with the same focused purpose when you are engaged with a hot project.

Unfortunately, “productive you” has been dulled by the recession. You look at the clock. It’s 9:03- Your hot project lost budget. 9:07- You start to feel like you’re just hanging out at the office, daydreaming about the receptionist or what you’re going to do this weekend. 9:13- “Will I be the next budget cut?” Or maybe you’re forced into endless, mindless, maintenance and you begin to feel like the same worthless, infinite loop that “victim you” is attempting to debug. Maybe you’ve become a cash cow and you’ve lost touch with the leading edge you once steered like a snowboard. If you resent, but resemble this description, STOP. It’s time to wake up the “pro-active you”.

Learn and Grow. It even sounds healthy and positive, like water and sunlight to a plant. I’m not going to try and talk you out of investing in night school, but you don’t need money, homework and someone else’s schedule to learn. There’s a lot of negativity about our current economy. Want a silver lining? There has never been a time when you and I could take advantage of the plethora of free information for educational purposes as we can today. Think about it. “How would you like your free industry knowledge, miss? For here (seminar)? To go (white paper)? or delivered into cyberspace (webinar)?”

Complimentary subject matter expertise and contributing back to the community are key foundational components of the Savid Technologies business model. In my Security Practice Manager role, I am deep into developing an immense library of IT security and compliance literature. It’s already pretty solid. Savid’s Marketing team, in conjunction with our Web Development team, has created an easy and efficient self service system for your convenience. Just check it out at www.savidtech.com. Look for new, relevant and insightful information every month on technology, methodology and industry metrics. On our website, you can also view the upcoming complimentary, educational events, or download our informative whitepapers. If what you are looking for is not there yet, just contact Kelly or Angela in Marketing (877-307-0444). They’ll hook you up with free industry knowledge, for here, to go, or delivered into cyberspace. I will also make time to discuss IT security with you. If I don’t know it, I will connect you with the right resources.

One last note. Consider attending our monthly Chicago IT Security Meetup. Next meeting’s topic and registration can be found at: http://www.meetup.com/The-IT-Security-Group-of-Chicago/. I gotta go now and finish my week’s work; I’ve got a long list of research topics for Saturday morning.

My article on Virtualization Security just went live on InformationWeek.com, if you want to read the juicy details (incoluding charts and graphs!), go read the article right now! Security Tips for Virtualization

The article is a summary of the 40+ page report I wrote for InformationWeek Analytics, the research division of InformationWeek. While researching for the report I needed to provide an update on virtualizaiton security that InformationWeek did in 2008, so I had the opportunity to meet and interview a couple CISOs in the cloud, SaaS, and traditional IT roles. It was clear that that is a lot of confusion when it comes to virtualizaiton security but all the CISOs said that virtualizaiton has moved from the test/qa areas into full fledged production and no one could stop it. The benefits far outweighed the security concerns.

So what are you going to do when you are told by IT that the beta virtualization environment is going into production in two weeks? Focus on preventing these common problems:

>> Loose controls: Implement strong change management that is auditable and mandates a separation of duties. The logins used to manage the virtual infrastructure must not have access to anything but the virtualization management software. Also, all virtualization infrastructure changes should be logged, and those logs reviewed by someone not on the virtualization team.

Events such as restarting VMs, creating new VMs, and adjusting hardware should always be correlated to reasons they were done.

>> Shoddy virtual network design: Virtual networks are complex, mainly because of the abstraction. Go slow, use Visio, and map it all out so proper segmentation is deployed and security control points (these are where security controls can be installed) are defined before the virtual network is created. Think about firewalls, IPS/IDS, Web application firewalls, and routing.

>> Unsecured physical data stores: Make sure the spot where your VMs and snapshots are stored is not easily accessible. If an attacker or malicious insider can access your virtual disk files, it’s game over. This includes backups. Don’t put backups of virtual disks on a public file server, ever.

>> Thinking VSAs will solve the problem: You don’t need virtual security appliances to manage most virtualization risks. Is there anything wrong with using your physical IDS/IPS or firewall and trunking the VLANs to the virtual switch? We don’t think so. Use what you have. If you want to add VSAs to address performance problems, fully test the appliances at adequate load before you buy.

>> Believing what you hear in the news is real risk: Don’t be reactionary. Thinking the latest virtualization attack you saw at Black Hat will affect you next week will only result in you having to take some real blue pills to reduce stress. Most of these attacks are still in the theoretical stage and simply aren’t practical for attackers because they don’t deliver quick ROI.

Related articles

• Hypervisor Security: Don’t Trust, Verify (informationweek.com)
• Security Tips For Virtualization (informationweek.com)