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.

I just released a report for Dark Reading on how to build a multi-enterprise vulnerability management program. If you are dealing with outsourced vendors, or an outsourced supply chain, you should definitely give the article a read.

To summarize the article:

1. Get your legal contracts in order. So many firms don’t put what they need from their partners into a contract. How do you expect to get what you need then?
2. Establish Communication channels that work for everyone. If you don’t get the right people on the “phone”, nothing will get done – including your security processes
3. Find the person with authority at your partner and ensure they are involved, otherwise your efforts will be useless.

I offer many more details and tips within the article but step #1 is so critical that an entire article should be dedicated to just that!

Verizon Business Christian Moldes as a great post about Plane Crashes and Security Breaches and how they are very similar. He hits it right on the head! During our engagement wrap-up meetings where we explain the various potential scenarios an attacker can use to break into a client’s network we are always asked to put a specific ranking on a specific risk. I argue that that almost doesn’t matter because normally the big breaches are not from a single vulnerability but many chained together.

Christian quotes Malcom Gladwell, and says:

The typical [plane] accident involves seven consecutive human errors.

When we work with clients we normally see that breaches are caused by a chaining of at least three errors: exploitation of a vulnerability, then a mis-configuration is used to find a privileged account user name and password, and then data is found on the network somewhere it wasn’t supposed to be that the privileged account has access too.

Even with many controls in place you cannot always prevent a security breach. This is the exact reason why we recommend that incident response policies and processes (Which should be tested like you test your Disaster Recovery processes!) should be the FIRST THING you implement when building a security program at an organization followed by detective controls such as logging to detect a breach as soon as possible.

If you are annoyed by the constant updating, amending, and general tinkering of HIPAA compliance regulations, then you may have to get used to it. The proposed healthcare reform bill not only contains additional HIPAA provisions but a proposal for periodic updates.

At this moment, the healthcare reform bill has just passed a key Senate committee. Within the 1,000 page document are proposals for regular HIPAA renewals that would allow for biannual reviews of existing HIPAA standards and operation rules, and the ability to make recommendations and updates.

The bill proposes four additional HIPAA transactions for healthcare industries where their data and information must comply with the most current standards and operating rules – health claims, enrollment/disenrollment in plans, health plan premium payments, and referral certification and authorization. The bill would give healthcare industries until 2015 to get compliant in these areas. There is also a list of proposed penalties for those who fail to comply to the HIPAA requirements.

The healthcare industry already had to adjust to HIPAA amendments that were caveats to accepting money in Obama’s economic stimulus bill earlier this year. Those amendments manifested in the Health Information Technology for Economic and Clinical Health (HITECH) Act extended HIPAA regulations to business associates and required notification to patients in the event of security breaches. While HITECH provided $31.2 billion for healthcare infrastructure and adoption of electronic health records, it also increased compliance obligations and strengthened enforcement penalties.

The bill basically makes government regulation of healthcare IT regulatory with biannual updates to HIPAA. I’m not sure if more government regulation and compliance is going to improve the quality of healthcare privacy for individuals, but I am sure that many will oppose these changes.

Of course there’s no guarantee the bill will not change drastically as it goes through the House of Representatives on the next leg of its journey. And, even then, it may or may not be passed by Congress and signed by Obama.

Bruce Scheiner is talking about a great post at the Boston Review about the new age of cyber-warfare, and how cyber-warfare is greatly exaggerated. I couldn’t agree more. Granted, the US government has a cyber-warfare problem. All governments do, however, the bigger problem that is more real today is cyber-crime. I spoke at the Federal Reserve last week on this exact topic.

Small businesses are now being targeted because they have more money in their accounts and it is easier to transfer larger sums of money out of their accounts without fraud detection going off at banks.

A quote from the review sums it all up:

So why is there so much concern about “cyber-terrorism”? Answering a question with a question: who frames the debate? Much of the data are gathered by ultra-secretive government agencies—which need to justify their own existence—and cyber-security companies—which derive commercial benefits from popular anxiety. Journalists do not help. Gloomy scenarios and speculations about cyber-Armaggedon draw attention, even if they are relatively short on facts.

I try very hard not to do what they describe when I speak but it can be difficult especially to those that are not familiar with the problem.Cyber-crime is the death by a thousands cuts type of problem. $3,000 here, $5,000 there, but it all adds up pretty quickly. Cyber-warfare is much bigger and easier to point at than these small little fraud issues.

If you have 10 minutes of time, read the Boston Review article and give me some feedback. Are we in a situation where we as citizens have to be concerned about cyber-warfare like we were concerned about nukes in years past?

Patch Tuesday is kind of like a monthly holiday for many businesses I work with.  It gives employees a chance to kick back while their computers and systems do all the work of updating (Yes, I am joking).  But is Patch Tuesday really a good idea?  Many have expressed concerns about creating a consistent trend to patching that informs attackers about the update patterns of their targets.

Here are the three main disadvantages to the system of Patch Tuesday:

1. Patch Tuesday, by its very nature, makes exploits public.  So while Patch Tuesday may make things easier for those who take the time to patch, it severely damages those who do not.  Not only are exploits announced but hackers can analyze the patch to figure out exactly how to take advantage of unpatched systems.  For this reason, the existence of Patch Tuesday actually makes the need to patch that much greater.

2.  By having so many patches downloaded at the same time by so many systems, there is a definite toll on the bandwidth.  This could tie up the bandwidth on your corporate network.  But it is a much greater problem on a vendor’s servers who must contend with downloads from everyone who uses their products.

3. If you wait until a set time before patching, then you allow for your software to remain vulnerable until then.  It’s not a big problem when the vulnerability is not widely known, but there have been cases where the vulnerabilities were made publicly known for months before patches were available.  Either way, hackers have a fair amount of time to take advantage of the exploit before it is corrected with the patch.

Ultimately, whether you participate in Patch Tuesday or not depends on the nature of your unique enterprise.  Some organizations cannot afford the risks of waiting to patch and require more vigilant updating to protect their systems.  Other organizations may value the fluidity of operations over security and prefer a monthly scheduled time for patching.

Consider this:  A hacker finds a security hole on your website that exposes hundreds of thousands private customer data including names, emails, and even passwords.  The hacker does not steal this information.  Instead, he quietly alerts you via email; but at the same time he makes the security vulnerability public information on his blog.

Do you: A) Thank the hacker for bringing the security vulnerability to your attention?  Or, B) seek legal action against the hacker who damaged your company’s reputation by alerting the public about your sloppy security?

This is the controversy surrounding “HackersBlog.org” – a blog where anonymous hackers alert the public about security vulnerabilities.  Each blog entry lists the site hacked, how the data was captured, and what private information is accessible.

The site made its first splash when a Romanian hacker named “Unu” hacked the databases of Kapersky – ironically, one of the leading companies in the security and antivirus market.  “Seems incredible but unfortunately, its true,” writes Unu, “Alter one of the parameters and you have access to EVERYTHING: users, activation codes, lists of bugs, admins, shop, etc.”

The next target, which occurred the very next day, was BitDefender – another antivirus software company.  Unu used an SQL injection to show how data could be easily extracted.

In an official statement, Kapersky denied the attack was successful.  BitDefender called the hack an attack and portrayed it negatively even though “the action did not intend to steal information but simply show a vulnerability.”  Usually when sites are hacked, the companies are left scrambling to put out the public relations fires.

So, alerting the website via email about the found vulnerability?  That sounds white hat enough.  So why expose the flaw to everyone publicly on the Internet and wreck the reputation of that company?  “If we just send an email, without making it public they would fix only that parameter that we announced,” says Unu, “and it is possible [for there] to be others too.”

It seems that HackersBlog owes its allegiance to the public and not to the companies who allow for these breaches in security.  “I’m not a criminal, I [am] not a burglar,” says Unu, “You do the work of a [pentesting firm] that could test the security of the site or [sic] server at the request of the owner. The difference is that the firm makes this for a big sum of money, a very big sum of money, and we do it as a hobby, for pleasure, free, and most of the times we do that much better, but we don’t even get a simple ‘Thank you.’”

Leave me a comment and let me know what you think about this Hacker Blog site!

The reality of the situation is that there is no such thing as a 100% secure place on Earth.  IT security professionals can only do what they can to make things as secure as possible.  There is no computer security defense that will succeed every time, forever, or as I say when presenting at conferences “You cannot buy your security at the local best Buy”. (NOTE: If you have an indepth udnerstanding of heypots, you can skip this post)

Because of my interaction and association with the Honeynet Project I am frequently asked what benefits honeynets can provide to the normal everyday IT security engineer. Simply put, honeypots provide us with early warning so we can be vigilant and prepare our defenses accordingly. 

Additionally, honeypot data is a great way to loosen the purse strings of corporate managers who are hesitant to dip into the company budget.  You can make a case for a larger IT security budget by showing them the attack data on the honey pot – who is attacking, how they are attacking, how often, and, most importantly, what damage they could potentially do to the enterprise if the proper defenses are not built.  Actual data speaks louder than any verbal argument.

Here’s an analogy to help you understand the importance of honeypots. 

Imagine you are tasked with defending your king’s castle from an impending enemy attack.  But you don’t know who the enemy is, where they are coming from, how many there are, or what kind of attacks they will use.  They may use spears, rifles, or just sharp rocks.  They may attack on horseback, with catapults, or maybe with tanks.

So what kind of defenses should you build?  A 30 foot tall wall surrounding the castle or a moat?  Should you put archers in the towers or build turrets?  Maybe you should just pile up a few sandbags and hope for the best. Maybe the real problem is the village idiot on the inside… =)

Without knowing anything about the impending attack, you do not know what an appropriate defense would be.  You may dig a futile trench around your castle while the enemy attacks with stealth bombers.  Or you may encapsulate your entire castle in an impenetrable crystalline dome while your five attackers sling rocks at it.  The latter defense may work, but your king might not be too happy with you for wasting his whole treasury on an unnecessarily robust defense.

A Honeypot is perhaps like a decoy paper version of your castle set up a mile before your actual king’s castle.  The paper castle has no value, but you can see what attacks your enemy uses when they attack it, and thus prepare accordingly.

Honeypots allow you to understand what kind of attacks you can expect.  With this knowledge you can allocate resources to defenses appropriately, without under or overspending. Now, with all that said not everyone can run out and install a honeypot and solve their problems. Honeypots require a lot of maintenance, watching, and i fnot properly installed you can actually decrease the security of your network.

If you don’t want to take the chance of hurting your own security posture, there are services that will configure and run honeypots for you and provide you with their data. Symantec and McAfee offer such services.

If you work in the health industry then you might be really thankful for that $31.2 billion provided in President Obama’s Economic Stimulus Bill.  The Health Information Technology for Economic and Clinical Health (HITECH) Act will provide the funds for the healthcare infrastructure to adopt electronic health records (EHR).  But be warned, this isn’t a free lunch from the government.  That HITECH money comes with a steep price tag.

HITECH expands the scope of HIPAA adding some new privacy and security requirements.  These include public notification of security breaches, complying with individual requests regarding PHI (Personal Health Information) disclosure, and giving electronic PHI to those individuals that request it.  But sure to be one of the more annoying requirements is accounting for PHI disclosures.  Every time a patient’s PHI is disclosed in the form of treatment, payment, or other health care operations, a record must keep account of each and every disclosure.

Also, now business associates of healthcare providers will fall under the growing canopy of HIPAA.  Any business that contracts with a HIPAA covered entity and routinely accesses PHI must now also be HIPAA compliant.  This will include Health Information Exchange Organizations, Regional Health Information Organizations, or any other vendor that contracts that with a covered entity to allow that covered entity to offer a personal health record to patients as part of its electronic health record.

But these changes are not what worry me.  What worries me is the shift from the Office of Civil Right’s compliant-driven approach to enforcing HIPAA to the new OCR-funded approach.  Effective immediately, collected civil moneys from HIPAA neglectors goes directly to the OCR.  That’s right; the OCR is now driven by a cash incentive to find HIPAA violators, as opposed to just waiting until someone complains about it. 

While HIPAA has mostly been a toothless tiger up to this point, we can expect the OCR to act much more aggressively and prosecute violators further now that they get to keep whatever they can collect. 

The cash penalties are steeper now with HITECH.  “Did not know” or “reasonable cause” violations will be fined $100 to $50,000 for each incident.  Entities that show “willful neglect” will be given a minimum fine of $10,000.

Because of HITECH, ignoring HIPAA compliance just became a bigger gamble than ever.

When HIPAA was passed and made federal law by the Clinton administration in 1996, the fear of fines and even jail time sent the medical industry scrambling to beef up their patient data security by the 2003 deadline.  However, for years afterwards, HIPAA remained a toothless tiger.  Occasionally, it growled and violators were threatened to clean up their act.  But it usually did not bite, as prosecutions were rare and usually mild.

Since no serious prosecutions have taken place since HIPAA went into effect in 2003, I and the medical industry have wondered if HIPAA is just a made-up boogeyman meant to frighten them into compliance. 

All this changed on February 18 when the U.S. Department of Health and Human Services and the Federal Trade Commission issued a press release stating CVS had to pay $2.25 million to the U.S. government for HIPAA violations.

The HHS Office for Civil Rights (OCR) and the Federal Trade Commission caught the pharmacy chain red-handed disposing of empty pill bottles that contained patient data into dumpsters and trash containers outside select stores.  Among other issues, CVS “failed to implement adequate policies and procedures to appropriately safeguard patient information during the disposal process; and failed to adequately train employees on how to dispose of such information properly.”

CVS Caremark Corp., the parent company of the 6,000 store pharmacy chain, must implement a robust corrective action plan that requires Privacy Rule compliant policies and procedures for safeguarding patient information in addition to its fine.  CVS must also submit to a biennial audit by a third party to show their compliance.

Is HHS trying to set an example with the steep penalty?  Is CVS the sacrificial lamb intended to inspire other delinquent HIPAA violators to clean up their act? 

While many medical industry companies may have gambling with HIPAA violations, at least CVS learned it isn’t worth the risk.  Besides the possible penalties, compromising personal patient data is a strike against the reputation of a company.  And this can be more costly than any fine by the HHS.