Oops! I Leaked My Data

The hot topic these days in security seems to be DLP or Data Leakage Prevention. Personally, when I someone says "data leakage" I immediately think of incontinence. I can't help it, in some (many) ways I am still an 11 year old boy. In all seriousness, I think this is yet another solution looking for a problem. Kinda sorta. In my meetings with various DLP vendors I am beginning to get the sense they are selling re-purposed, bass-ackwards IDS. Basically you have to either tap or span an egress port at your edge and inspect relevent packets heading for the exit. If the informtion heading out is not encrypted and matches predetermined criteria (signature-based) if will act according to the business rules set on the device (drop, log, etc.). The DLP solutions I have been exposed to also have a desktop client that will monitor for pre-defined data types and will try to lock this data down so it can't leave the machine without proper authorization. At least that's what the product brochure says. :eye roll:

In most enterprises you need an iron grip on your infrastructure in order to pull off an effective DLP deployment. By iron grip I mean effective controls such as:

• Accurate directory structure to determine user semantics
• Finance users should be able to see financial data
• Finance users should not be able to see IT data
• Corporate data standards that define data by type, sensitivity, and audience
• File servers that are locked down to prevent users from "folder surfing"
• Corporate desktop that is locked down and strictly enforced (can't install/uninstall apps)
• Web proxies that are capable of blocking traffic and can work with the DLP system
• Single point into and out of the enterprise network to prevent data "leaking out the back door" (sorry, couldn't help it)

I think products like DLP have their place in the corporate environment, however, I think the vendors are promising things they can't deliver except in a lab environment or in small tightly run shops. In my opinion DLP will become mature when it is integrated with a web proxy and possibly an inbound IDS/IPS solution. Oh, and it has to have powder-fresh scented and original unscented models.

Tap Dancing in a Minefield

or How to be an Effective Security Professional I am learning very quickly that an information security professional has to wear many hats and has to be a subject matter expert on a wide array of subjects. But ultimately no matter how much training and how many controls and policies are put into place the effectiveness of a security pro will be measured by the amount of buy- n the business has into security as a concept and how much security is on the minds of architects, developers, and administrators. If you don't have their cooperation you will find yourself chasing down and trying to correct fundamental problems that could have been prevented in the early stages of the life cycle. You will have have a group of very talented people trying to find ways around your controls and policies from within your enterprise. Definitely not a win-win. So how do security professionals deal with this issue? How do we get everyone on the same page to march toward a more secure enterprise? I find that there are times where the art of social engineering comes in quite handy when dealing with people within your own company. Depending on the ego, excuse me, person I am dealing with and my knowledge of the subject I will employ some of the following techiques in order to better secure applications and system from the ground up. Let's discuss what the options are... I use this one when people come to me early in the SDLC. I want to encourage this behavior so I will absolutely let the developers and architects help guide the security profile of their project. I actually enjoy this method the most as I learn the most from discussing why certain security features or functions may not be feasible but something I hadn't thought of could be used in its place. If you were going to get into this app, how would you do it? This is for the times when I am a shown a completed architecture but am little unfamiliar with the technology deployed or if I don't see any apparent weakness in the proposal. I dont use it that often but when I do architects and developers typically have fun with the question and come up with some pretty wild scenarios I would never lose sleep over. The Socratic Method (or Doing the Machiavelli) This technique is for the times when I am given an architecture or proposal that has holes that are pretty easy to see or if I know which direction I want to head in but don't want to issue edicts. I will start asking pointed questions to get the architects and developers thinking on a certain track, slowly (sometimes painfully) leading them to the design flaws or the inherent weaknesses. When I get them to see the issue, I will begin another line of questions that gets them towards the solution I think is best. Of course I will listen to them if they convince me that fears are unfounded or if there are mitigating controls I don't see or didn't know about. What do you want me to say? I took this one straight from the auditors playbook. Sometimes political pressures are put upon architects and developers to do things they know are wrong. So they come to me looking for my disapproval along with the rationaile they can take back to their superiors. Sometimes the security professionals role is that of official bad guy and who am I to disappoint? If we could tear this down and start over... This one is reserved for legacy systems that are being refreshed using the same design and architecture as the previous version. Whether the reason is technical constraints, political pressure, or intellectual laziness, I try to re-invent the wheel whenever possible so I use this method to get the creative juices of the developers and architects going. Sometimes the architecture get approved as-is with minimal changes but I have also seen complete redesigns after I have posed this question in a meeting. You will respect my authoritah! This is the nuclear option for security professionals. I have to use this one every so often but I have it at the ready at all times. If a project manager, developer, business unit manager, etc. are not willing to budge on their proposal despite my attempts to get them to make their system more secure I will dig my feet in, draw the proverbial line in the sand, and basically force someone above my head to override me. I guess in some ways it's a CYA manuever that shifts the blame if something goes wrong and my vocalized fears are realized. This is a very short list, and most of the time I use techniques that incorporate more than one of the above with others I haven't included. Securing a large enterprise is a difficult task that cannot be solved with technology alone. I am fairly confident I will write about this subject in the future, perhaps with some concrete examples of how I used one the techniques to make an insecure proposal into a (more) secure system.

Perimeter Security

Makes for a happy h4x0r.

Podcast Review: Wireless Dangers at Airports

NetworkWorld Panorama Podcast with Jason Merrick from AirTight Networks I spent my Sunday morning catching up on some older podcasts I haven't had time to listen to but had interesting subjects. One in particular, "Wireless Dangers at Airports" from NetworkWorld Panorama on 5/8/2008 piqued my interest as it was directly related to my current employer. As I listened to the podcast I had thoughts ranging from "interesting" to "yeah, but" and "that's FUD." Quick Summary: 14 Airports in the US, UK scanned

• 77% of networks found were private networks
• 80% of those had either WEP or no encryption

Airports:

• "large" number used for logistics
• ticketing
• baggage
• stores
• restaurants
• Using WEP or Open for business use

Users:

• 3% used corporate VPN
• SSID leakage
• Viral WLAN

Example:

• Baggage tracking WLANs
• "BetaBaggageSystem" was an SSID
• WEP encrypted

Worst case scenario:

• DOS baggage or ticketing system
• hide baggage
• reroute baggage
• enter ticketing system

My thoughts:

• 14 is a very small statistical sample but I believe the finding would be similar if the sample size was large
• Hotspots have not proliferated because only a select number of providers are allowed into the airport space and the have to share the frequency space with legitimate business use WLANs so the 77% number is what should be expected.
• The use of WEP is a very touchy subject. I like almost everyone else in the infosec field agree that WEP should be banished from the wireless landscape. Unfortunately, corporations rushed out five or six years ago with the encouragement of vendors to rapidly deploy wireless networks. The standard at the time was WEP and unfortunately the cost of going back and migrating up to WPA or WPA2 is going to cost millions per airline.
• As for the logistical use of wireless in airports, once again, the business benefit of wireless far exceeds the risk. Also, I think there is a basic assumption that once you gain access to the WLAN you would have unfettered access to the baggage system or the ticketing system (as Jason Merrick of AirTight Networks states more than once during the podcast). I would make the assumption that business traffic being broadcast over the WLAN via WEP is encrypted via a SSL tunnel and that there is two factor authentication and authorization in place. Therefore, the assumption that you could just reroute a bag or book yourself a ticket is greatly exaggerated (read: FUD).
• Jason mentions hiding SSIDs as a risk to wireless users and thus the enterprise. Now depending on my mood I would either agree or disagree (I see both sides of the subject) but it must be said that until PCI eliminates the mandate for hiding the SSID that the corporate environment has its hands tied on the matter and opinion plays no part. I cannot design a solution that purposefully disregards PCI (or any other statute) because I think they are incorrect and I know better.
• I agree that we need to try and force our users to use the IPSEC VPN clients we provide to them. But since I can't be everywhere, we filter web access through a corporate gateway proxy, and we offer HTTPS access to email as an alternative (for the CEO when he's visiting Mom's house for instance), it appears that using a VPN is an unattractive and restrictive way to do some quick work while waiting for a flight.

Overall I think Jason's study is worthwhile (although I question his motives a bit... trying to get my attention?) and his findings are somewhat accurate, but his assumptions and conclusions are way off base and smack of fear-mongering and FUD.

Baking Compliance into the SDLC

The executives at my company "suggested" that we should include the PCI DSS into our enterprise SDLC. My first thought when I heard that suggestion was "no." Not in "no, that is a terrible idea" but "no, I think you are missing the point of statutes such as PCI, HIPPA, etc." The point of compliance is to force the enterprise to maintain a minimum level of security in the areas that the standard or statute are concerned. For example, PCI only cares about credit card information, HIPPA is solely concerned with medical information, SOX financial data, etc. and those statutes only mandate minimum controls around the data of concern. What about the rest of the data? What percentage of data that is traversing the corporate network involve these other data types? What data is important to the business besides financials? What data, if exposed, would put lives in danger? Of course PCI, HIPAA, et. al. protect important information belonging to customers and employees alike. But what about intellectual property? If you are an airline would a flight manifest or crew assignment be of interest to a potential hijacker/terrorist? If you are a shipping company would a cargo manifest of drugs being sent cross-country be of interest to thieves? Obviously, some of the data that is critical to the functionality of the business is also some of the data that can do the most harm if compromised. To get back to the topic at hand let's consider "baking" parts of the PCI DSS into the SDLC. I can write the SDLC that forces PAN masking and encryption. From my experience, the issue that will develop is that anything that is not included in the SDLC will not be masked or protected. For example, if I don't include driver license or social security numbers the developers will assume that they must not be sensitive and will not protect them. So I will have to include them in the SDLC. What about addresses and phone numbers? Frequent-flier accounts? Travel history? How do you protect sensitive operational information? Flight manifests, crew lists, employee rosters, the list goes on and on. What this leads to is policy that is over-developed, confusing, contradictory, and most of all, impossible to enforce. I do understand and agree with the sentiment of getting security involved early and often in software and systems development. Instead of focusing on bare the minimum to avoid lawsuits and prosecutions we should look at developing best practices that will secure all data and systems that reside within the enterprise. Guidelines and policies that force the architects and developers to identify data they will be dealing with and how the business views that data is a good first step to protecting the data by hashing, encrypting, or masking, etc. To aid architects and developers during the initiation portion of the SDLC we as security professionals must make every effort to bring some common sense to securing the proposed application. The fact that many projects make it all the way to testing and/or deployment before security finds out about it is why the industry has been reduced to bolt-on solutions, insecure networks, swiss-cheese firewalls, and vulnerabilities galore. But that is a subject for another post (or 50).

Shifting the Security Paradigm in a Large Enterprise

Since I have taken over as Sr. Security Architect (a.k.a. corporate whipping boy) at my current employer I have been trying to convince anyone that listens to me that more firewalls does not equal more security. I have reviewed the configurations of literally dozens of firewalls and routers and have seen big-eye Swiss cheese with fewer holes. Add that to complex rules governing communication and the fact that the data centers are hosted by several different vendors with different rules governing change management, vendor relations, equipment specifications, etc. and it became very clear to me that big changes are needed. The first thing that management needs to understand is that simplicity and visibility is the key to good security architecture. Complexity is the friend of the hacker and a network that has more layers than an onion makes it impossible to see anything... good or bad, it all looks the same. So what do we do? Some of the areas I am focusing on is: Simply network/firewall architecture and rules Why block port 1521 into a zone that only has databases? Any server that goes into the zone has to submit several firewall requests in order to open a port that every other server in that zone has already opened. Thus, we can apply global rules to help aid both security and admins. Couple that with utilizing advances in hardware that enable us to place a firewall module blade into a chassis that can handle many “virtual” interfaces on a single physical connection. Gain visibility into your traffic flow Yes, yes this subject is being beaten to death in the infosec blogosphere but management has gotten the memo yet, that we are already allowing the bad guys in. The advent of w2.0 has enabled some killer new applications and has brought the user closer to the data. Unfortunately, due to fact that we have relied on IP firewalls we are allowing the bad guys into the data center unescorted.

IDS/IPS IPS is great but sucks at logging and false positives are always a concern for management. IDS is great for information gathering but is slow, isn't inline, and tells you what happened, not what is happening. Brian Smith at TippingPoint gave a good keynote about this dilemma at RSA 2008 and proceeded to describe their attempt at a solution to the problem. I will wait to see if their technology shakes out but the idea is still there... IPS where you can, and IDS where you can't. WAF Web Application Firewalls are the new golden boy thanks to the PCI mandate that either you perform a security code audit on your relevant web apps or you stick an box inline that inspects the packets as they come into your data center. I plan on watching a lot more than just PCI-relevant apps in time but this is one time where compliance is a net good.

Vulnerability Scans You don't know what you don't know... this helps you shine a little light on the dark corners of your network. Knowing your soft spots helps you 1) keep an eye on, and 2) plan your strategy on defending them. Centralized Logging This is the key to me. You can have a great IDS sensor deployment, hardened IP firewalls, a WAF inspecting all your web traffic, etc. but if you don't have eyes on glass looking at the data then what you have are a bunch of expensive space heaters. A security analyst should be able to look at the "hit" logs from all the devices at their disposal... routers, firewalls, IDS/IPS, WAF, scans, etc. and should gain insight to what is going on... once traffic patterns are established anomalies are more quickly spotted and investigated. Policies Putting all of the above, and oh so much more, into documents such as policies, strategies documents, technical documentation, coding standards, etc. in vital to maintaining a consistent security posture across the enterprise. Updating those documents on an ongoing basis is also very important. Threats, laws, technology, and the business needs will constantly be changing and your documentation must reflect these changes. Communication I try to listen to and lean on the architects within the organization when it comes to their areas of expertise. Just as they come to me for guidance regarding security, I also go to them when I don’t understand a certain system/technology. As much as I like to think I know… I know there are oceans of information out there I haven’t sailed, yet. ☺ I will call this part 1 of an X part series since I haven’t touched on encryption, law, compliance, audit, etc. I also haven’t discussed how to deal with the problems heterogeneity brings with multiple vendors in a hosted environment. Oh, and I haven’t even touched the … I think you get the point! Yes, I know the title stinks. I'll think of something snappier for part deux. Stay tuned.

Continental tests electronic boarding pass at Logan

As a follow up to my earlier post about allowing electronic boarding passes it appears that Continental has got an official program underway in Boston. I wonder how it works... has anyone out there gotten to board a plane by using their phone? I sense I will have to start coming up with recommendations about this pretty soon.