Research

I have very little social life, so I spent my weekend researching trends in database security. Part of my Saturday was spent looking at Microsoft’s security model for the Azure SQL database platform. Specifically I wanted to know how they plan to address database and content security issues with their cloud-based offering. I certainly don’t follow all things cloud to the degree our friend Chris Hoff over at RationalSurvivability does, but I do attempt to stay current on database security trends as they pertain to cloud and virtual environments. Rummaging around MSDN, looking for anything new on SQL Azure database security, I found Microsoft’s Security Guidelines and Limitations for SQL Azure Database. And I downloaded their Security Guidlines for SQL Azure (docx). All 5 riveting pages of it. I have also been closely following the Oakleaf Systems blog, where I have seen many posts on secure session management and certificate issuance. In fact Adam Langley had an excellent post on the computational costs of SSL/TLS this Saturday. All in all they paint a very consistent picture, but I am quite disappointed in what I see. Most of the technical implementations I have looked at appear sound, but if the public documentation is an accurate indication of the overall strategy, I am speechless. Why, you ask? Firewall, SSL, and user authentication are the totality of the technologies prescribed. Does that remind you of something? This, perhaps?   With thanks to Gunnar Peterson, who many years ago captured the essence of most web application security strategies within a singe picture. Security minimalism. And if they only want to do the minimum, that’s okay, I guess. But I was hoping for a little content security. Or input validation tools. Or logging. I’m not saying they need to go wild with features, but at this point the burden’s on the application developer to roll their own security. Share:

In our last post we introduced some of the key principles of incident response. Today we will focus on the major roles and organizational structure. Organizational Structure As we return to our IT security focus, the incident response organization consists of two major kinds of resources: those dedicated completely to response, and those with other primary functions who get pulled into incidents as needed depending on the scope or nature. For example, the legal team isn’t necessarily involved in every incident, but clearly plays an important role in anything with legal or regulatory consequences. Also, a smaller organization might have no dedicated resources, while a larger one may have a full time team with defined roles, which deals with multiple overlapping incidents. That’s okay because the structure and system can expand and contract as needed if you follow the ICS principles. Resources These individuals and roles may not spend all their time on incident response, but are the key roles to fill when an incident occurs. One person can fill multiple roles, especially for a smaller incident or organization, but only if they have the right skill set. Team Lead/Incident Commander: The person with overall responsibility and accountability for the direct management of incidents. Typically reports to the CISO, CIO, or even CEO, but following unity of command, should definitely only be accountable to a single manager. When an incident triggers, the first person to respond is the incident lead until they hand off responsibility to someone of equal or higher authority. That way someone is always in charge, even if only for the first few minutes. Command is then handed off to higher and higher levels as needed. When you have a full-time team, the team lead/manager is also responsible for ongoing training, program development, and so on. Network Analysts: Experts in analyzing network packets/traffic, including forensic captures. Analysis includes ongoing monitoring, as well as deeper investigation during incidents. Systems Analysts: Experts in analyzing endpoints and servers. Forensics Analysts: Often a subspecialty of systems analyst, these individuals have deeper training in forensic investigation – which includes both the technical skills for the forensics examination of a system, and the legal training to properly handle evidence if there may be legal considerations (keep in mind that merely firing someone may lead to civil legal action). SIEM/Log Management Analysts: Individuals experienced in monitoring SIEM output and log analysis. Network, Systems, Database, and Application Administrators: Those individuals responsible for the maintenance of systems and networks. It is their responsibility to implement defensive mitigations during and after an incident, and to clean up affected systems. A firewall/IPS administrator might be responsible for closing the entry or egress points being used by the attacker. Systems administrators might roll out patches or configuration changes to host firewalls. A DBA might change account permissions or close out connection methods. This is a rather large bucket, and in most organizations these people operate at the direction of dedicated incident responders or other members of the security team. Legal, Human Resources, and Risk: Any time an incident might involve legal action, employees, or a material costs, you should involve any required combination of these business units. Communications/PR: If an incident has public impact, such as breach notifications, it’s critical to involve those responsible for organizational communications. Accounting/Finance: Incident response costs money. It’s important to include the bean counters early, even if only to pay for the pizza and Red Bull. They can also take responsibility for tracking ongoing incident costs so those of you responsible for stopping and cleaning the problem don’t have to spend your time spinning accounting spreadsheets. Logistics: This role can be a bit nebulous, but includes those responsible for getting the things you need during an incident. It may be someone from finance, the purchasing team, or the security team. Basically it’s someone with a credit card and the authority to use it. They keep people fed, purchase needed hardware and software, and hire outside experts. Communications: Those responsible for making sure responders (and management) can communicate. You might only need this role in a big incident, but make sure you identify people ahead of time who can keep you talking – via cell phones, landlines, email, IM, or whatever other mechanism isn’t totally pwned. Executive Management: We list them last, but they are ultimately responsible for everything in the organization – including incidents. Except in the organization’s very largest incidents, they probably won’t be involved directly. Yes, that is a large number of potential roles, but remember that not all are needed for every incident, and the same person might fill multiple roles based on organization and incident size. For example, in a small or mid-sized organization it isn’t unusual to have the team lead also be the network and systems analyst, and possibly also responsible for cleaning systems or reconfiguring the firewall. In terms of structure, here is one approach:   Finally, don’t forget our key concepts for the organizational structure: People should only report to a single manager. Any manager should only command 3 to 7 other people, ideally 5. The organizational structure fills in resources as needed. You don’t need everything, and what you do need you don’t need all the time. This is a scaffold to build on, not a permanent building. Share:

Imagine you’re a young, skilled techie just starting your career. Maybe you’re fresh out of school, or still in an internship program. Or maybe you’ve been out of school for a few years, working your way up through various companies in the industry. You came from a normal background – possibly you thought about the military at some point, but the allure of working in technology drew you into the private sector. Your skills are solid, you produce at work, and you don’t get into any trouble beyond the usual for your age. Then one day you’re contacted by someone in the government who was sent your way by a buddy from school, or maybe an old professor. They need someone with your skills to help them out with a project. Perhaps it’s to join their agency directly. Or maybe they merely ask you to take a look at something for them – sort of steering you toward a bit of a grey area you wouldn’t normally explore because you don’t want to get in trouble. They tell you it’s a matter of national security, and this is finally your opportunity to give back to your country without having to get shot at. Heck, maybe you spent time in the military and this is a great opportunity to continue your service on a volunteer basis without getting stuck with crappy military pay and travel/deployment requirements. Perhaps you already work for a foreign company your government friends are worried may be a risk to national security. All they want is for you to provide a little information, or maybe plug a USB drive into a system in the office for a few minutes. Or maybe you’ve been working for them on some projects for a while, even if they don’t really pay you and merely “suggest” things for you to look at. You’ve done a good job and they ask you to apply for some work or study abroad in another country. Or for a foreign company in your country. Either way, all they’re asking for is you to further your education and career, maybe helping your country out a little along the way. Ethically this is no different than joining the military, an intelligence agency, or working for a private contractor or university on government projects. You are serving your country while advancing you career – pretty much the best of both worlds. You can’t talk much, if at all, about it with your friends and family, but you sleep at night with the satisfaction that you’re able to blend the needs of your nation with your own personal development goals. Did I mention you grew up outside Shanghai? The thing about espionage is that there are no good guys or bad guys. Merely patriotic individuals living in different places who believe, with complete conviction, that they are doing the right thing and serving the public good. Share:

What a wild few weeks. Talk about been there, done that, got the t-shirt. It all started October 9th, when I finally achieved a goal I’ve been chasing for well over a decade, and completed my first Olympic-distance triathlon. (1.5K swim, 40K bike, 10K run – those are distances, not dollar values). I first learned about triathlon when I was working as a medic for a race in Boulder – probably back in 1992. Being the young, aggressive type, I thought any sport where you write your number on your arms and legs in permanent ink had to be hard core. I spent most of those years competing in a sport where you hit people in the face a lot (I guess that’s kind of hard core too), but in the late 90’s I started traveling a lot for work, which made staying competitive at the level I was at pretty much impossible. Getting frustrated by not being able to make it to the next level (I was competing nationally, but only winning locally), and spending a lot of time injured due to overtraining, I decided to give tri a shot. At least I could run, and often swim or bike, when on the road. But then I got sick… really sick. As in people started calling me “liver boy” because some virus attacked my third favorite part of my body and I couldn’t drink for over a year, never mind sustain hard workouts. But I recovered, started working with a swim coach, and then got distracted by getting married and traveling even more. And then I tore my rotator cuff and had surgery. And then had a kid. And… you get the idea. About 4-5 months ago I was finally injury-free and working out regularly again, and decided to give it another shot. Started riding with a bike group and then joined a masters swim program. I figured another 3 months of training and I’d be ready, but my swim coach pushed me to race and I gave it a shot. I may have finished near the back, but I finished. Easily. And now I’m hooked. Next up is a marathon, and maybe a half-Ironman in a year or so. Then back to the booze. The day after the tri I boarded a plane and headed off to London for RSA Europe. Chris Hoff and I spent a bunch of (platonic) private time together, and it turns out we’ve been working on some extremely complementary research that we’re going to combine for our joint RSA presentation this year. I was also really happy my work passed the sniff test, because Chris spends a heck of a lot more time on cloud than I ever will, and if the research holds up for him I know it’s solid. Then back home for 3 days, and back on a plane to China. I was again presenting with Hoff, and we managed to sneak out for a few hours to visit the Forbidden City. Which is quite welcoming, if you buy a ticket. They have beer. All reds for some reason. On a sour note, the day before the tri I got word that a very good friend died of cancer. Jim launched my technology career and changed the course of my life in ways that are hard to describe. A little over a year ago we started on some collaborative smart grid research, soon after which he found out about the cancer he never recovered from. Jim deserved better. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich in China. In Chinese. Mike quoted in Dark Reading on SIEM and cloud. Dave Lews and David Mortman get a mention in an article on SecTor. Rothman again, this time on consolidation. Rich talks about China and Europe on The Network Security Podcast Favorite Securosis Posts Mike Rothman: The Thing about Espionage. Clearly a fine line between good and bad. But I do think there is right and wrong. And regardless of how you slice it, if it’s called espionage, it’s probably wrong. Adrian Lane: React Faster and Better: Incident Command Principles. Rich: Can we ever break IT?. (We’re light on posts this week, so we’ll leave it at that.) Other Securosis Posts React Faster and Better: Roles and Organizational Structure. SunSec Rises on November 3rd. Incite 10/27/2010: Traffic Ahead. NSO Quant: The Report and Metrics Model. Everything You Ever Wanted to Know about DLP. Favorite Outside Posts Adrian Lane: Robert Graham’s FireSheep analysis. Mike Rothman: Cloud Creates SIEM Blind Spot. Keep in mind the cloud changes the rules for how we do things like monitoring. And I’m quoted. Enjoy the gratuitous pat on my own back… Chris Pepper: iPhone Jailbreak Tool Sets Stage for Mobile Malware. Eric Monti demonstrates that “jailbreak” = “remote root exploit”. Gunnar Peterson: Paypal enables billing and payments on Azure cloud. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics – Device Health. NSO Quant: Manage Metrics – Monitor Issues/Tune IDS/IPS. Research Reports and Presentations Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution, v2.0. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Top News and Posts Koobface Worm Targets Java. NSA Declassified Documents. Interesting stuff. Adobe Flash Bug. Perhaps we should leave a permanent reference in the Friday summary for Flash vulnerabilities and just update the link du jour. Idiocy tool. Just to remind people they are insecure. Firesheep launched. Critical Firefox Bug. LinkedIn Drive-by Malware Attack. 19 Arrested in Zeus Malware Bank Heists. Oracle claims Google directly copied Java code. Silver Tail Systems gets In-Q-Tel funding. Banks weak against skimming attacks. PCI Council releases a “sort of” update. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Mike Fratto, in response to The Thing About Espionage. Rich, based on your definition, the good guys are us and the bad guys are them for any definition of “us”

For those of you in the Phoenix area, or with way too many frequent flier miles and too much spare time, the Phoenix OWASP chapter is organizing a SunSec meetup after their meeting on November 3rd. It has been a long time since we had a real SunSec, after getting off to a good start a few years ago. This is a great excuse to meet up with local security folks over your favorite frosty beverages. SunSec will be held from 6:30 onward on November 3rd at SunUp Brewing. Share:

I saw an old friend last week, and we were talking about the business of Securosis a bit. One of the questions he asked was whether it’s a lifestyle business. The answer is that of course it is. Rich, Adrian, and I have done lots of things over the years and we all have independently come to the conclusion that we don’t want to work for big machines any more. We all have different reasons for that, and I was reminded of one of mine on Monday. Traffic. The mere mention of the word makes me cringe. Not like the Low Spark of High Heeled Boys (YouTube) cringe, but the cringe of wasted time. I’ve been lucky in that even when I did have an ‘office’, my commute was normally less than 15 minutes. But for most of the past 10 years, I’ve worked from a home office, which really means from random coffee shops and lunch joints. But on Monday I had to take a morning flight, and I wanted to help out the Boss and get the kids ready for school. I figured it wouldn’t be a big deal to leave 30 minutes later to head down to Hartsfield (Atlanta’s airport). I was wrong. Instead of the 35 minutes it normally takes, I was in my car for almost 80. Yeah, almost an hour and a half. I couldn’t help but feel that was wasted time. Even more, I feel for the folks who do that every day. I mean there are people who drive 70 or 80 miles each way to their offices. Now I’m not trying to judge anyone here, because folks live where they do for lots of reasons. And they work where they work for lots of reasons. Some folks don’t feel they can change jobs or can’t find something that’ll work closer to home. But you have to wonder about the opportunity cost of all that commuting time. Not to mention the environmental impact. Now to be clear, I’m a novice commuter. I didn’t have any podcasts loaded up to listen to or audio books or phone calls to make first thing on Monday morning. Yeah, who the hell wants to hear from me first thing in the morning? So there are more productive ways to pass the time. But that’s not for me. I want my biggest decision in the morning to be which coffee shop to hit and when to make sure I have no exposure to traffic. And it works much better for me that way. – Mike Photo credits: “Rush Hour” originally uploaded by MSVG Incite 4 U Hot wool for you… – The big news this week was the release of a new Firefox plug-in called Firesheep, which basically implements dead simple sidejacking over a wireless network for key social network sites. Like Facebook and Twitter. I saw sidejacking of a Gmail account by Rob Graham at BlackHat about 3 years ago, so this isn’t a new attack. But the ease of doing it is. Rich uses this as another reminder that Public WiFi is no good, and you can’t dispute that. Sure we could get all pissy that this guy released the tool, but that’s the wrong conclusion. I suggest you think of this as a great opportunity to teach users something. You can Firesheep their stuff in the office or in a conference room and use that to show how vulnerable their sites are. I suspect it will have the same educational effect as an internal phishing attack, meaning it’ll shock the hell out of the users and they may even remember it for more than an hour. This piece on GigaOm goes through some of the preventative measures, such as connecting via SSL when that is an option, and using a VPN to encrypt your traffic. Both are good ideas. – MR Bass ackwards (more on Firesheep) – Joe Wilcox argues that the new Firesheep Firefox Plugin is akin to “Giving Guns to Kids”. He claims that, because it’s so easy for anyone to see the cleartext password and cookies that are being blasted around the planet at the speed of light, nearly anyone can compromise an account. I can’t quite comprehend what Mr. Wilcox is thinking by calling the plugin ‘abominable’, as it is simply shining a powerful spotlight on stupidity that has been going on for a long time. Every semi-skilled criminal is doing this today – or more precisely has been doing this for almost a decade. Can the plugin turn kids into hackers? No, but it gives them a handy tool if they did not already have one. But it will help make a lot more people aware of the stupidity going on with web providers, and of logging in over untrusted wireless connections. Better to learn that lesson on Toys ‘R Us than Wells Fargo. – AL Reconcile that, Gunnar – I’ll admit it: I’m a big fan of Gunnar and my man crush has grown since he’s joined our team as a Contributor. Watching the man at work is a learning experience for me, and that’s a good thing. But in his Reconcile This post he’s missing part of the story. He unloaded on security folks for solving yesterday’s problems by making firewalls the highest priority spend. If he’s talking about traditional port-based firewalls, then I’m with him. But I suspect a great deal of those folks are looking at upgrading their perimeter defenses by adding application awareness to the firewall. We described this in depth in our Understanding and Selecting an Enterprise Firewall paper. These devices address social network apps (by enforcing policy on egress), as well as helping to enforce mobile policies (via a VPN connection to leverage the egress policies). I realize GP is talking about the need to focus on the root cause, which is application and higher-level security. But security folks don’t generally control those functions. They do control the network, which is why they usually look to solve whatever security problem they have with an inline device. When all you have is a hammer, everything looks

I know what you’re thinking to yourself right now: “They promised me a cool series of posts on the cutting edge of incident response, and now we’re talking management principles and boxes on an org chart? What a rip.” But believe it or not, the most important aspect of incident response is the right organization, followed by the right process. How do I know this? Because I’ve been through a ton of incident response training with local and federal agencies, and have directly responded to everything from single-rescuer ski accidents to Hurricane Katrina. (And a few IT things in the middle, but those don’t sound nearly as exciting). While working as an emergency responder I fall under something known as the National Incident Management System, which uses a formalized process and structure called the Incident Command System (ICS). ICS consists of a standard management hierarchy and processes for managing temporary incidents of any size and nature. ICS was originally developed for managing large wildfires in the 1970s, and has since expanded into a national standard that’s also used (and adapted) by a variety of other countries and groups. While our React Faster and Better series won’t to teach you all of ICS, everything we will talk about in terms of process and organization is adapted directly from it. There’s no reason to reinvent the wheel when you have something with over 30 years of battle-hardened testing available. Additionally, those of you in larger companies or verticals like healthcare or public utilities may be required to learn and use ICS in your own incidents. Incident Command System Principles ICS solves a lot of the problems we encounter in incidents. Its focus is on clear communications and accountability, with a structure that expands and contracts as needed, allowing disparate groups to combine even if they’ve never worked together before. ICS includes 5 key concepts: Unity of command: Each person involved in an incident only responds to one supervisor. Common terminology: It’s hard to communicate when everyone uses their own lingo. Common terminology applies to both the organizational structure (with defined roles, like “Incident Commander”, that everyone understands) and use of plain English (or the language of your choice) in incident communications. You can still talk RPC flaws all you want, but when communicating with management and non-techies you’ll use phrases like “The server is down because we were hacked.” Management by objectives: Responders have specific objectives to achieve, in priority order, as defined in a response plan. No running around fighting fires without central coordination. Flexible and modular organization: Your org structure should expand and contract as needed based on the nature and size of the incident. The organizational structure can be as small as a single individual, and as large as the entire company. Span of control: No one should manage less or more than 3-7 other individuals, with 5 being the sweet spot. This one comes from many years of management science, which have repeatedly confirmed that attempting to directly manage more is ineffective, while managing less is an inefficient use of resources. If you want to learn more about ICS you can run through the same self-training course used by incident responders at FEMA’s online training site. Start with ICS 100, which covers the basics. While the process we’ll outline in this series is based on ICS principles, it’s specific to information security incident response. We won’t be using terms like “branch” and “section” because they would distract from our focus, but you can clearly plug them in if you want to standardize on ICS. But if you need the Air Ops branch for a cyberattack, something is very very wrong. For the next post we will focus on three of the key concepts related to organizational structure: unity of command, flexible and modular organization, and span of control, as we talk about the key response roles and structure. Share:

It has been a long slog, but the final report on the Network Security Operations (NSO) Quant research project has been published. We are also releasing the raw data we collected in the survey at this point. The main report includes: Background material, assumptions, and research process overview Complete process framework for Monitoring (firewalls, IDS/IPS, & servers) Complete process framework for Managing (firewalls & IDS/IPS) Complete process framework for maintaining Device Health The detailed metrics which correlate with each process framework Identification of key metrics How to use the model Additionally, you can download and play around with the spreadsheet version of the metrics model. In the spreadsheet, you can enter your specific roles and headcount costs, and estimate the time required for each task, to figure out your own costs. In terms of the survey, as of October 22, 2010 we had 80 responses. The demographics were pretty broad (from under 5 employees to over 400,000), but we believe the data validates some of the conclusions we reached through our primary research. Click here for the full, raw survey results. The file includes a summary report and the full raw survey data (anonymized where needed) in .xls format. With the exception of the raw survey results, we have linked to the landing pages for all the documents, because that’s where we will be putting updates and supplemental material (hopefully you aren’t annoyed by having to click an extra time to see the report). The material is being released under a Creative Commons license. Thanks again to SecureWorks for sponsoring this research. Share:

Facebook is for old people. Facebook will ultimately make us more secure. I have learned these two important lessons over the last few weeks. Saying Facebook is for old people is not like saying it’s dead – far from it. But every time I talk computers with people 10-15 years older than me, all they do is talk about Facebook. They love it! They can’t believe they found high school acquaintances they have not seen for 30+ years. They love the convenience of keeping tabs on family and friends from their Facebook page. They are amazed to find relatives who have been out of touch for decades. It’s their favorite web site by far. And they are shocked that I don’t use it. Obviously I will want to once I understand it, so they all insist on telling me about all the great things I could do with Facebook and the wonderful things I am missing. They even give me that look, like I am a complete computer neophyte. One said “I thought you were into computers?” Any conversation about security and privacy went in one ear and out the other because, as I have been told, Facebook is awesome. As it always does, this thread eventually leads to the “My computer is really slow!” and “I think I have a virus, what should I do?” conversations. Back when I had the patience to help people out, a quick check of the machine would not uncover a virus. I never got past the dozen quasi-malicious browser plug-ins, PR-ware tracking scripts sucking up 40% of system resources, or nasty pieces of malware that refused to be uninstalled. Nowdays I tell them to stop visiting every risky site, stop installing all this “free” crap, and for effing sake, stop clicking on email links that supposedly come from your bank or Facebook friends! I think I got some of them to stop clicking email links from their banks. They are, after all, concerned about security. Facebook is a different story – they would rather throw the machine out than change their Facebook habits because, sheesh, why else use the computer? I am starting to notice an increase in computer security awareness from the general public. Actually, the extent of their awareness is that a lot of them have been hacked. The local people I talk to on a regular basis tell me they and all their children, have had Facebook and Twitter accounts hacked. It slowed them down for a bit, but they were thankful to get their accounts back. And being newly interested in security, they changed their passwords to ‘12345’ to ensure they will be safe in the future. Listening to the radio last week, two of the DJs had their Twitter accounts stolen. One DJ had a password that was his favorite team name concatenated with the number of his favorite player. He was begging over the air for the ‘hacker’ to return his access so he could tweet about the ongoing National League series. Social media are a big part of their personal and professional lives and, dammit, someone was messing with them! One of my biggest surprises in Average Joe computer security was seeing Hammacher Schlemmer offer an “online purchase security system”. Yep, it’s a little credit card mag stripe reader with a USB cable. Supposedly it encrypts data before it reaches your computer. I certainly wonder exactly whose public key it might be encrypting with! Actually, I wonder if the device does what it says it does – or anything at all! I am certain Hammacher Schlemmer sells more Harry Potter wands, knock-off Faberge eggs, and doggie step-up ladders than they do credit card security systems, but clearly they believe there is a market for this type of device. I wonder how many people will see these in their in-flight Sky Mall magazines over the holidays and order a couple for the family. Even for aunt Margie in Minnesota, so she can safely send electronic gift cards to all the relatives she found on Facebook. Now that she regained access to her account and set a new password. And that’s how Facebook will improve security for everyone. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Tech Target article on Database Auditing. Adrian’s technical tips on setting up database auditing. Rich at RSA 2010 China. Favorite Securosis Posts Mike Rothman: Monitoring up the Stack: Climbing the Stack. Then end of the MUTS series provides actionable information on where to start extending your monitoring environment. Adrian Lane: Vaults within Vaults. Other Securosis Posts React Faster and Better: Data Collection/Monitoring Infrastructure. White Paper Goodness: Understanding and Selecting an Enterprise Firewall. Incite 10/20/2010: The Wrongness of Being Right. React Faster and Better: Introduction. New Blog Series: React Faster and Better. Monitoring up the Stack: Platform Considerations. Favorite Outside Posts Mike Rothman: Reconcile This. Gunnar calls out the hypocrisy of what security folks focus on – it’s great. The bad guys are one thing, but our greatest adversary is probably inertia. Gunnar Peterson: Tidal Wave of Java Exploitation. Adrian Lane: Geek Day at the White House. Chris Pepper: WTF? Apple deprecates Java. Actuallly they’re dropping the Apple JVM as of 10.7, but do you expect Oracle to build and maintain a high-quality JVM for Mac OS X? A lot of Mac-toting Java developers are looking at each other quizzically today. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics – Device Health. NSO Quant: Manage Metrics – Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics – Deploy and Audit/Validate. NSO Quant: Manage Metrics – Process Change Request and Test/Approve. Research Reports and Presentations Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Security + Agile = FAIL Presentation. Data Encryption 101: A Pragmatic Approach to PCI. White Paper: Understanding and Selecting SIEM/Log Management. White Paper: Endpoint Security Fundamentals. Top News and Posts A boatload of Oracle fixes. Judge Clears CAPTCHA-Breaking Case for Criminal Trial Data theft overtakes physical loss. Malware pushers abuse Firefox warning page. Predator

I was reading one of RSnake’s posts on how our security devolves to the lowest common denominator because we can’t break IT – which means we can’t make changes to systems, applications, and endpoints in order to protect them. He was talking specifically about the browser, but it got me thinking a bit bigger: when/if it’s OK to break IT. To clarify, by breaking IT, I mean changing the user experience adversely in some way to more effectively protect critical data/information. I’ll get back to a concept I’ve been harping on the last few weeks: the need to understand what applications & data are most important to your organization. If the data is that important to your business, then you need to be able to break IT in order to protect it. Right? Take the next step: this means there probably should be a class of users who have devices that need to be locked down. Those users have sensitive information on those devices, and if they want to have that data, then they need to understand they won’t be able to do whatever they want on their devices. They can always choose not to have that data (so they can visit pr0n sites and all), but is it unreasonable to want to lock down those devices? And actually be able to do it? There are other users who don’t have access to much, so locking down their devices wouldn’t yield much value. Sure, the devices could be compromised and turned into bots, but you have other defenses to address that, right? But back to RSnake’s point: we have always been forced to accept the lowest common denominator from a security standpoint. That’s mostly because security is not perceived as adding value to the business, and so gets done as quickly and cheaply as possible. Your organization has very little incentive to be more secure, so they aren’t. Your compliance mandate du jour also forces us toward the lowest common denominator box. Love it or hate it, PCI represents that low bar now. Actually, if you ask most folks who don’t do security for a living (and probably a shocking number who do), they’ll tell you that being PCI compliant represents a good level of security. Of course we know better, but they don’t. So we are forced to make a serious case to go beyond what is perceived to be adequate security. Most won’t and don’t, and there it ends. So RSnake and the rest of us can gripe about the fact that we aren’t allowed to break much of anything to protect it, but that’s as much our problem as anything else. We don’t make the case effectively enough that the added protection we’ll get from breaking the user experience is worth it. Until we can substantiate this we’ll remain in the same boat. Leaky as it may be. Share: