Red Gecko: controls

Showing posts with label controls. Show all posts

Friday, April 24, 2009

Tuesday, January 13, 2009

Data Breaches on the Rise

In my Jan. 1 posting, SANS 2009 Security Predictions, I referenced the Identity Theft Resource Center and the timely studies that they release concerning data breach trends. Their new report details a 47% increase in US data breaches over 2007.

Not surprisingly, the two areas called out in the breach statistics were lack of encryption and lack of passwords on the breached data. Password protection is a pretty weak method of protecting your data, given the computing power available today to brute-force or dictionary attack the passwords. Even using pass-phrases instead of passwords is less than effective, depending on the length of the phrase, as some platforms simply hash and store the result, and breaking the smaller hash is relatively simple.

One sector that showed the largest increase in reported breaches was in the business category, increasing 36.6% in 2008, after posting smaller increases of 28.9% and 21% in 2007 and 2006 respectively. Government/Military and Education actually saw decent decreases over the same timeframe.

Only 2.4% of all reported breaches had encryption or other strong protective controls in use. 7.3% of the business breaches involved data in transit - either via backup tapes, removable media, or in some cases, electronic data movement, which could include misdirected or erroneous transmissions. Overall, data on the move and accidental exposure account for 35.2% of all breaches with a cause determined, and both fall into the "human error" category.

There is vigorous debate among security and privacy professionals about these trends, and the discussions typically take one of two approaches - we're a lot better at identifying breaches as they occur via preventative and detective controls, and we're doing a better job of complying with state data breach notification laws and regs. While both are true to an extent, I firmly believe there's one other point to be made.

There's still too much data being created and stored, and we've yet to achieve a good maturity model for controlling access to data based on a clear need for people to have the data in order to do their jobs. At every step in the information lifecycle, from creation to destruction, how well do we understand what data we have, where it's located, how it's protected, and who has access to it? When information moves during use, whether from web apps into back-end systems, from collection points to databases, or from data stores to applications or tools that parse, analyze, or process the data, where are the gaps in our controls environment and how do we close them? Do you have a good methodology for testing the effectiveness of the applicable controls, including documentation about what sort of evidence is sufficient to substantiate whatever controls effectiveness rating you plunk down on a particular measure?

The Computer Security Division of the National Institute of Standards and Technology has just released SP 800-122 DRAFT Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), open for comment through March 13, 2009. NIST presents a general, but effective overview of how to protect PII that is applicable to data of all types, especially if your organization struggles to differentiate between data types. NIST obviously recommends performing data analysis to ascertain the types of data you hold, assigning risk classifications to the various data types, and implementing security and control based on risk.

Most mature organizations have some sort of information classification program, but the wheels come off somewhere between tagging the data and reporting that the data is breached. The challenge is to perform a root cause investigation to see where you went wrong. Did you fail to risk assess the data types, or did you not apply the controls that were applicable based on data and risk classifications? Or perhaps you applied the controls and it turned out your testing didn't identify control gaps or the existence of ineffective controls. Maybe you did identify control gaps, but either didn't have remediation plans in place, or the breach occurred before you could complete your remediation. Perhaps human error was involved in any (or all) of these phases, or you didn't enforce separation of duties or other best practices.

Until we all get our arms around the concept of controlling how much data we collect, retain, process, and store, and enforcing stringent protection mechanisms at every phase of the information lifecycle, we'll continue to see disturbing breach trends. It's only a matter of time until the incoming Obama administration begins to push for federal data protection and breach notification legislation as an umbrella approach to supplant the myriad state laws and regulatory agency requirements while pushing a straighforward, easily-measured enforcement framework.

At this point, I'm not convinced that moving to a federal model is a bad thing. Time will tell.

Tuesday, December 30, 2008

2009 Security: Kevin's Crystal Ball

We've seen a lot of movement in information security trends in the past year, not all of it good. Particularly disturbing is the notion that good security policy is in many cases an output of these trends, rather than an input that sets into motion tactical responses designed to implement your overall security strategy.

Put more simply, don't run your security program like some companies run their IT projects, where someone falls in love with a technology or gadget, then tries to wedge it into their infrastructure without much regard to the business problem you're trying to solve.

There are risks in this world, and you can't anticipate or prepare for them all. The sooner you acknowledge that, the better off you'll be. Corporate information risk and control is a dynamic environment, and you need to be agile in your security posture to ensure it adjusts not only to the changing threat landscape, but to your firm's developing business needs.

Which brings us back to some key things to consider as we move into a new year.

Security policies - it's time for a review to ensure that your policies for data privacy and protection are clearly articulated, meet overall business requirements, and are adequate in the face of both a rapidly changing business/financial environment and shifting regulatory landscape.

Security processes - have you successfully deployed solutions that implement your policies? Do you have the right people, in the right roles, employing the right technology in a standard, repeatable manner? Let's not forget the accepted definition of a process - it's standard and repeatable.

Audit trails - are you collecting the right data for audit purposes, and can you demonstrate a clear, defined audit trail for external examiners, regulators, and third-party assessment teams? Do you keep your security teams honest by having their work evaluated from the outside, and can you demonstrate compliance to good security practices like separation of duties, span of control, and job rotation?

Prevention - do we go beyond detective controls, where we learn after the fact that something is wrong, to employ preventive measures such as access controls, encryption, digital signing, IDS, IPS, and so on? A layered security posture not only makes it more difficult for the black hats to compromise your data, it also increases the probability that one or more of your early warning systems will alert you to an attack in progress. You can then kick in your robust incident response team process. You do have one of those, don't you?

So what do I see on the horizon? Here's the top 5 things that will make noise in 2009.

Endpoint security - we've spent so much time, effort, and money trying to secure our knowledge repositories, data warehouses, server farms, and storage environments that we've begun to overlook what happens when this data is pulled to a client system where it's processed, analyzed, and otherwise at risk. I'm not talking just about the evolution of antivirus, antispyware, and personal firewalls here. Data control elements need to be part of that equation - what's happening to the information, how is it being used, and where is it going? Are you spending millions to harden your data centers only to have your sensitive information breached on a desktop, laptop, or handheld device, or is it being passed out via email, FTP, SSH tunnels, and so on?
Secure virtualization - with a strong move to Virtual Desktop Instances (VDI) and server OS virtualization, we need better ways to lock down these emerging environments. In many cases, legacy approaches to solutions like role-based access controls, identity and access management, network-layer security, and state monitoring leave significant gaps when operated in a virtual world.
Secure software - when are software vendors going to begin to be held accountable for selling us insecure software offerings? Probably not in 2009 - but that doesn't mean the push can't start. Think of how much less security you'd have to implement if operating systems and applications were hardened out of the box, and you weren't continuously running on the treadmill of vulnerability identification, patching, and repeating? How many times have you taken a secure box, loaded an app, and found huge security holes had opened, or you had to dial down your security settings in order to get the app to work correctly? Let's keep pushing software vendors to do the right thing, but while we're at it, let's ensure we're building robust security parameters into our internal software development lifecycle. The best executed security program can easily be short-circuited by a crappy web app or user developed tool. Run your internally-generated code through a rigorous application security assessment and pen test program, one that's separate and distinct from the app dev groups.
Information lifecycle approach - think of your firm's information in the same manner that the Secret Service thinks of executive protection. Information is the target, so how do we protect the target at all times, from when the information is first created, through its use and transmission, following it through storage and eventually to destruction? What are the threats that exist at every phase, and what controls are in place at every single step to mitigate those threats? How effective are the controls, and are they constantly tested and revised in the face of new and emerging vectors? How do you substantiate your controls effectiveness?
The business of security - how integrated is your information systems risk and control program with the overall business plan and strategy? Do you know what's on the horizon, and is your security infrastructure ready to support it? The cost of implementing a new business strategy can be staggering, and having it fail due to security breach or incompatible security architecture is simply unacceptable. As a security professional, it's your responsibility to understand the business drivers and to present effective control solutions that protect the firm's information and systems while allowing the business to grow and prosper. If you don't understand the business roadmap, there's no way your technology path will succeed.

Leveraging the Internet has completely changed business, and security with it. No longer is a network viewed as a medieval castle, with tall strong walls, surrounded by a deep moat, with the good guys on the inside of the castle and the bad guys on the outside.

Walls don't exist in cyberspace. There are only barriers, and everyone knows there are ways around them. It's time to get away from the fortress mentality when it comes to security. Today, some of the bad guys are on the inside, and a lot of the good guys are on the outside, needing in to be able to do their jobs.

If you're dedicated to prevention - the fortress - you'll soon learn there's no such thing as Camelot. It's such a silly place. Make sure you're spending a big chunk of your time on detection and response, too.

Happy 2009!

Tuesday, December 23, 2008

World Bank Bans IT Vendor

It's been months since reporters started pelting the World Bank with questions about rumors that hackers had infiltrated their records and stolen large amounts of financial data.

Being a global financial organization, the World Bank did what any pseudo-respectable organization would do - they stonewalled like hell.

Indirectly confirming what many of us already knew to be true, the World Bank admitted that a leading India-based IT vendor, Satyam Computer service, was barred nearly a year ago from doing any business with the bank, and the ban started in September. Hmmmm. Think there's a connection?

This makes it a bad week to be Satyam, which deals with roughly 1/5 of Fortune 500 companies as clients, and also trades on the NYSE. These relationships reportedly generate about $2 billion is sales as part of outsourcing agreements.

Trends toward outsourcing of critical IT functions make it even more necessary to apply IT controls and substantiation requirements to vendors that are at least as robust, and in many cases much more so, than a firm's own internal controls.

From an information lifecycle perspective, how is information tracked from creation to destruction, and at all points in between? What controls are in place, and what sort of testing is performed to validate the effectiveness of those controls?

When controls are found to be ineffective, what steps are taken to either enhance these controls, supplement them, or replace them with entirely different control sets?

What are the hand-off points for critical data points? When data is created, how is it transmitted and utilized? What systems process the information, and who has access to the data, including system and database admins who provide maintenance and support?

Is separation of duties enforced, and are security admin roles kept segregated and distinct from production roles? What's the audit methodology, and how are the IT control audits validated?

Finally, how is information protected as it's moved from production to storage? Encryption, anyone? Access control?

How about destruction? When the information is no longer needed for business reasons, how is it destroyed, and what sort of validation is provided?

Business today is all about information - creating it, using it, running analytics and spinning out reports to be actioned, data warehousing, marketing, correlation and business intelligence.

Much like a company's business plan and future strategy, information is valuable and needs to be protected. Lax oversight by the World Bank shows what can happen if this responsibility is neglected. The only difference is that most people won't pull their deposits from the World Bank.