Research

I enjoy living in the South (of the US). I’m far enough North that we get seasons. But far enough South to not really be subjected to severe winter weather. It’s kind of like porridge in the story of the 3 bears. Living in ATL is just right for me. Usually. In a typical year, we’ll see snow maybe twice. And it will be a dusting, usually gone within an hour. Only once in the 6 years I’ve lived in Atlanta has there been enough snow to even make a snowman – and Frosty it wasn’t. Which is fine by me. But this weekend we got hammered. 6 inches in most places. I know, you rough and tumble Northerners laugh at 6 inches. That’s not enough to even start up your snow blower. I get that. But you are prepared and you have the right equipment to deal with the snow. We don’t. I’ve seen it written that Chicago has 200 snow plows. Atlanta has 8. Seriously. And I live about 30 miles north of Atlanta, so we have zero snow plows. Even if you get a few inches of snow, it’s usually above freezing, so it melts enough to clear the roads and get on with business. Not this time. When it got above freezing, we got frozen rain. And then it got colder, so anything that melted (or rained) then froze on the roads. I’m a good winter driver and I know enough to not mess with ice. I even had to shovel. Thankfully, I didn’t toss my good shovel from up North. It still worked like a charm – though my back, not so much. So basically I’m trapped. And so are the Boss and kids. They canceled school for the past two days, and it’s not clear (given the forecast for more freezing weather) that they will have school at all this week. Thankfully the snow is still novel for them, so they go out and sled down a hill in our back yard in a laundry basket. Yes, a laundry basket. That’s a southern kids’ sled, don’t you know? I’ll give the kids props for creativity. But a week at home with the kids without the ability to go do stuff is going to be hard. For the Boss. I’ll be sequestered in my cave looking busy. Very very busy. OK, I’m not totally trapped. I did escape for an hour this afternoon to brave the slush and other wacky drivers. I had to pick up a prescription and get some bread. The roads were passable, but bad. And to add insult to injury, Starbucks closed about 20 minutes after I got there, so I couldn’t even get much writing done. My routine is all screwed up this week. I know this too shall pass. The snow will melt, the kids will go back to school, and things will return to normal. But to be honest, it can’t pass soon enough. We love the kids. But we also love it when they get on the bus each morning and become their teachers’ problems for 6 hours. -Mike Photo credits: “Snowed in Snowdon” originally uploaded by zalgon Vote for Me. I’ll buy you a beer. OK, I’ll finally come clean. I’m an attention whore. Why else do you think I’d write this drivel every week? Yes, my therapist has plenty of theories. But it seems that some of you think this stuff is entertaining. Well, at least the judges of the Social Security Blogger Awards do. I’m both flattered and excited to once again be nominated in the Most Entertaining Security Blog Category. I actually won the award in 2008, but was crushed like a grape in 2009 by Hoff. And deservedly so. But this year Hoff is thankfully in another category, so my fellow nominees are Jack Daniel’s Uncommon Sense, the Naked Sophos folks, and some Symantec bunker dwellers from the UK. All very entertaining and worthy competition. I’ll reiterate an offer to buy a beer for anyone who votes for me, but there is a catch. You can only collect at the Security Bloggers meet-up at RSA. Seems Shimmy is on to my evil plans. So if you like beer. Or if you like me. Or if you feel sorry for me. Or if you want my Mom to be able to kibbitz with her group of Yentas in Florida about her entertaining blogger son. Help out a brother with a vote. Incite 4 U Brand this: George Hulme argues against the idea that security doesn’t matter to a company’s brand. George can (on rare occasions) be a disagreeable guy, but this one is a bit of a head scratcher. If the measuring stick for is stock price, then George is wrong. There has been no negative effect on stock price from a security breach. George states that companies suffering breaches have greater churn than those that don’t. But evidently not enough to impact their stocks. I did a podcast with Shimmy yesterday and toward the end we discussed this. My point is that clearly breaches cost money, both in terms of the direct costs and the opportunity cost of not doing something more strategic with those resources. Those are real costs. But do they outweigh the additional costs incurred by trying to be secure? That is the zillion dollar question. And there isn’t any data to prove it one way or the other. As Rich always preaches to us, we need to be very careful when we infer causation without specific data. Which I think has happened on both sides of this discussion. – MR Don’t blame the hinge manufacturer if you leave the door open: I get sort of annoyed when people blame someone else for their problems. Take the latest brouhaha over the brand new Mac App Store. It turns out – and you might want to sit down for this one – that if you don’t follow Apple’s guidelines on

At the risk of having Rich yell at me again (like he did early last year) because I’m writing too much high-level stuff, let’s get back to a key soft skill of being a security manager. It’s not like we got a lot better at that in 2010, right? I talked about motivating your team earlier this week, so now let’s turn to marketing and sales. Right – you are a security guy/gal, what do you need to know about sales? Well, unless your senior management comes to you with a blank check and a general understanding of how to protect your stuff, you need to map out a security program and sell it to them. If you end up with about 20% of the budget you need every year, and at layoff time you lose 40% of an already understaffed team, guess what? You have a sales problem. And that means you may have to get your Elmer FUDd on. A post by Dave Shackleford got me thinking about FUD (fear, uncertainty, and doubt) from a user context. It’s a constant presence when dealing with vendors, who are always trying to scare their customers into buying something. But end users can leverage FUD as well. Just be careful – it’s a bit like using live exploits. You might get what you want, but in the process take down the entire system. I’ve been talking for years about the need for security managers to focus on communications and leave the firewall rules to the admins. Part of that communication strategy is about creating urgency. Urgency gets things done. Urgency doesn’t allow folks to debate and get into an analysis/paralysis loop. You need urgency. And used correctly, FUD can create urgency. You are probably thinking about how distasteful this whole discussion seems. You can’t stand it when your sales reps try to throw a FUD balloon at you, and now you need to do the same thing? Just hear me out. The deal with using FUD in an end user context is pretty straightforward – it’s really just about telling the truth, the whole truth. And that’s really the difference. The amount of risk most organizations face can be overwhelming, so most security managers downplay it, or run out of time to tell the entire story. What you want to do is explain to senior management, preferably with examples of how it happened to other folks (who look like your company & managers), all the ways you can be compromised. Yes, the list is long. I recommend you do this within the context of a risk assessment and the associated triage plan to fix the most urgent issues. This process is outlined in Steps 2 and 3 of the Pragmatic CSO. You see, if you show them you can get killed 200 ways, but ask for funding to only fix 50, it’s a win win. The reality is even if you had the resources, you couldn’t fix all 200 anyway, and by the time you are done there will be another 200. But that can stay just between us. The senior folks think you are making tough choices to fix the stuff that’s most important and exposed – which you are. So as you hunt for those wascally wabbits each day, don’t be too scared to break out the Elmer FUDd from time to time. Sometimes the end justifies the means. But don’t tell the vendors I said FUD is OK (sometimes). That needs to remain our little secret. Photo credits: “Elmer Fudd” originally uploaded by Joe Shlabotnik Share:

Compliance and security have hit the big time, and I have the proof. Okay: all of us who live, eat, and breathe security already know that compliance is a big deal and a pain in the ass – but it isn’t as if “normal” people ever pay attention, right? Other than CEOs and folks who have to pay for our audits, right? And according to the meme that’s been circulating since I started in the business, no one actually cares about security until they’ve been hit, right? Well, today I was sitting at my favorite local coffee shop when the owner came over to make fun of me for having my Mac and iPad out at the same time. We got to talking about their wireless setup (secure, but he doesn’t like the service) and he mentioned he was thinking of dropping the service and running it off his own router. I gave him some security tips, and he informed me that in no way, shape, or form would he connect his open WiFi to the same connection his payment system is on. Because he has to stay PCI compliant. Heck, he even knew what PCI PA-DSS was and talked about buying a secure, compliant point of sale system! He’s not some closet security geek – just a dude running a successful small business (now in two locations). He’s a friggin’ Level 4 merchant, and still knows about PCI and compliant apps. I feel like kissing the sales guy who must have explained it all to him. And security? He never uses anything except his up-to-date Windows 7 computer to access his bank account. Now can we all shut up about not making a difference? Do you really think I could have had that conversation even a few years ago? One last note: RSA is fast approaching. We (well, @geekgrrl) are working hard on the Securosis Guide to RSA 2011, the Recovery Breakfast announcement will go out soon, we’re cramming to finish the CSA training class, and we’ve locked in an awesome lineup for the RSA e10+ program we are running this year. And then there’s our sekret squirrel project. In other words, please forgive us if we are slow responding to email, phone calls, or beatings over the head. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mort quoted in Incident%20response%20plans%20badly%20lacking,%20experts%20say. Kevin Riggins gives us a shout-out and review. Favorite Securosis Posts Mike Rothman: Mr. Cranky Faces Reality. Any time Adrian is cranky, you need to highlight that. I guess he is human after all. Adrian Lane: The Evolving Role of Vulnerability Assessment and Penetration Testing in Web Application Security. David Mortman: Web Application Firewalls Really Work. Rich: BSIMM meets Joe the Programmer. Other Securosis Posts React Faster and Better: Initial Incident Data. Mobile Device Security: Saying no without saying no. Incite 1/5/2011: It’s a Smaller World, after All. HP(en!s) Envy: Dell Buys SecureWorks. Motivational Skills for Security Wonks: 2011 Edition. Mobile Device Security: I can haz your mobile. Coming Soon…. React Faster and Better Chugging along. React Faster and Better: Alerts & Triggers. Favorite Outside Posts Mike Rothman: Quora Essentials for Information Security Professionals. Lenny Z talks about how to use the new new social networking thingy: Quora. I’m a luddite, so maybe I’ll be there in a year or two, but it sounds cool. Adrian Lane: thicknet: starting wars and funny hats. A couple weeks old, but a practical discussion of MinM attacks on Oracle. And Net8 is difficult to decipher. Rich: Slashdot post on how China acquires IP. I suggest the full article linked by Slashdot, but it’s a translation and even the short bits in the post are very revealing. Project Quant Posts NSO Quant: Index of Posts. Research Reports and Presentations The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Top News and Posts Researcher breaks Adobe Flash sandbox security feature. He did not actually break anything, but figured out how to bypass the restriction. Windows 0day in the wild. SourceFire buys Immunet. More perspective on Gawker Hack. Chinese hackers dig into new IE bug, says Google researcher. Breaking GSM With a $15 Phone … Plus Smarts. The Dubai Job: Awesome article in GQ on the assasination. Security risks of PDF. 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 mokum von Amsterdam, in response to NSA Assumes Security Is Compromised. One can not keep information secret that is accessable by >10 people over years, period. Mind you, ‘systems’ and ‘networks’ are not limited to the typical IT stuff one might think of but includes the people and processes. Trying to secure it is doomed to fail, so what one needs is to adjust the mindset to reality. Sorry, no spend-more-dollars solution from me… Share:

In this series we’ve tackled the threats these new handheld computers mobile devices present, as well as how we need to deal with folks culturally when they demand access to sensitive corporate information on mobile devices. As we wrap up this short series on mobile device security, let’s jump in and talk about a few things we can do to protect these devices. As we all understand that these mobile devices are really handheld computers, we need to think about the tactics that are successful for securing our more traditional computers. Admittedly, ‘successful’ may be a bit optimistic, but there are still many lessons we can learn from the controls we use to protect laptops. Some of these fall into a traditional security technology bucket, while others tend to be more operational and management oriented. But really, those distinctions are hair-splitting. Things like secure configurations and access policies contribute to the safety of the data on the device, and that’s what’s important. Tactic #1: Good Hygiene I know you hate every time you go to the dentist and see the little sign: Only floss the teeth you want to keep. I certainly do, but it’s true. As much as I hate to admit it, it’s still true. And the same goes for protecting mobile devices. We need to have a strong posture on these devices, in order to have a chance to be secure. These policies won’t make you secure, but without them you have no chance. Strong Passwords: If you have sensitive data on your mobile devices, they need to be password protected. Duh. And the password should be as strong as practical. Not a 40 digit series of random numbers. But something that balances the user’s ability to remember it (and enter it n times per day) against the attackers’ ability to brute force it. And you want to wipe the device after 10 password failures or so. Auto-lock: Along with the password, the device should lock itself after a period of inactivity. Again, finding the right setting is about your users’ threshold for inconvenience, the length of their passwords, and your ability to dictate something secure. 5-10 minutes is usually okay. Data encryption: Make sure the device encrypts data on it. Most mobile devices do this by default, but make sure. Continuous Hygiene With your dentist, doing a good brushing right before your appointment probably won’t going to fool him or her if you haven’t flossed since the last appointment. But unless you are checking constantly whether the mobile device remains in accordance with your configuration policies, you can be fooled. Just because you set up a device correctly doesn’t mean it stays that way. For traditional networks, a technology like Network Access Control (NAC) can be used to check a device when it joins the network. This ensures it has the right patches and right configuration, and has been scanned for malware, etc. You should be doing the same thing for your mobile devices. Upon connecting to your network, you can and should check to make sure nothing is out of compliance with policy. This helps block the user who gets his device from you and promptly jailbreaks it. Or does a hard reset to dump the annoying security controls you put in place. Or the one who turned off the password or auto-lock because it was too hard to deal with. Remember, users aren’t as dumb as we think they are. Well, some aren’t. So some of them will work to get around the security controls. Not maliciously (we hope), but to make things easier. Regardless of the security risks. Part of your job is to make sure they don’t manage it. Tactic 2: Remote Wipe Despite your best efforts, some users will lose their devices. Or their kids will drop them (especially the iDevices). Or they’ll break and be sent in for service. However it happens, the authorized user won’t be in control of their devices, and that introduces risk for you. And of course they won’t tell anyone before sending the device is into the shop, or losing it. So we get a memo asking for a replacement/loaner because they have to access the deal documents in the can. You need the ability to eliminate the data on the device remotely. This doesn’t have to be complicated, right? Authenticate properly and nuke it from orbit. Hopefully your user backed up his/her device, but that’s not your issue. Ultimately if there is sensitive data on the mobile device, you need to be able to wipe it from anywhere in the world. One caveat here is that in order to wipe the device you must be able to connect to it. So if a savvy attacker turns it off, or puts it into airplane mode or something, you won’t be able to wipe it. That’s why having an auto-wipe policy in case of 10 password failures is critical. At some point, someone will try to get into the device, and that’s when you want to be rid of the data. Tactic 3: Lock down Network Access It’s no secret that most public wireless networks are the equivalent of a seedy flea market. There are some legitimate folks there, but most are trying to rip you off. And given the inherent bandwidth limitations of cellular data, most users leverage WiFi whenever and wherever they can. That creates risk for us, who need to protect the data. So what to do? Basically, get a little selective about what networks you allow users to connect to. You can enforce a policy to ensure any WiFi network used offers some kind of encryption (ideally at least WPA2) to avoid snooping the network traffic. Or you can VPN all the devices’ network traffic through your corporate network, so you can apply your web filtering and other protections, with encryption to rebuff sniffers. Unfortunately this isn’t easy to swing in reality. Remember, these devices don’t belong to your organization, so mandating

I always read Gary McGraw’s research on BSIMM. He posts plenty of very interesting data there, and we generally have so little good intelligence on secure code development that these reports are refreshing. His most recent post with Sammy Migues on Driving Efficiency and Effectiveness in Software Security raises some interesting questions, especially around the use of pen testing. The questions of where and how to best deploy resources are questions every development team has, and I enjoyed his entire analysis of the results of different methods of resource allocation. Still, I have trouble relating to a lot of Gary’s research, as the BSIMM study focused on firms that have resources far in excess of anything I have ever seen. I come from a different world. Yeah, I have programmed at large corporations, but the teams were small and isolated from one another. With the exception of Oracle, budgets for tools and training were just a step above non-existent. Smaller firms I worked for did not send people to training – HR hired someone with the skills we needed and let someone else go. Brutal, but true. So while I love the data Gary provides, it’s so foreign that I have trouble disecting the findings and putting them to practical use. That’s my way of saying it does not help me in my day job. There is a disconnect: I don’t get asked questions about what percentage of the IT budget goes for software security initiatives. That’s both because the organizations I speak with have software development as a separate department than IT; and because the expedniture for security related testing, tools, development manpower, training, and management software are embedded within the development process enough that it’s not easy to differentiate generic development stuff from security. I can’t frame the question of efficiency in the same way Gary and Sammy do. Nobody asks what their governance policy should be. They ask: What tools should I use to track development processes? Within those tools, what metrics are available and meaningful? The entire discussion is a granular, pragmatic set of questions around collecting basic data points. The programmers I speak with don’t bundle SDL touchpoints in this way, and they don’t qualify as balanced. They ask “of design review, code review, pen testing, assessment, and fuzzing – which two do I need most?” 800 developer buckets? 60, heck even 30, BSIMM activities? Not even close. Even applying a capability maturity model to code development is on the fringe. Mainly that’s because the firms/groups I worked in were too small to leverage a model like BSIMM – they would have collapsed under the weight of the process itself. I talk to fewer large fims on a semi-regular basis, and plenty of small programming teams, and using BSIMM never comes up. Now that I am on the other side of the fence as an analyst, and I speak with a wider variety of firms, BSIMM is an IT mindset I don’t encounter with software development teams. So I want to pose this question to the developers out there: Is BSIMM helpful? Has BSIMM altered the way you build secure code? Do you find the maturity model process or the metrics helpful in your situation? Are you able to pull out data relevant to your processes, or are the base assumptions too far out of line with your situation? If you answered ‘Yes’ to any of these questions, were you part of the study? I think the questions being asked are spot on – but they are framed in a context that is inaccessible or irrelevant for the majority of developers. Share:

I’m happy to say the holiday season was pretty eventful for the Boss and her family. Her brother (and his wife) welcomed twin boys into the world right after Xmas. The whole process of creating life still astounds, and the idea of two at a time boggles the mind – even if you’ve been through it. Turns out we were up North when the new guys showed up (a week early), so we got to meet them in person. We live 600 miles apart, so that was an unexpected bonus. It also meant there was no shot at all of us attending the Bris. 8-day-old boys provide a little donation to the gods and everybody eats. It’s a festive occasion (for us – for the babies, not so much) and we hated the economic reality that we couldn’t travel to attend in person. But then over the hills we saw a glimmer of hope. Was it a plane? Nope. 5 tickets are just too much money. A train? Nope. Can’t take a day to go back and forth. It’s video conferencing. Sure, Skype is fun to do a little video conference with the grandparents from time to time. It’s also critical when traveling abroad, unless you like $2,000 phone bills. In this case, video allowed us to be at the Bris, from the comfort of our home office. The kids were off from school, and my brother in law set up his web cam to overlook the ceremony. So we all crouched around the computer and watched the ritual. We got to wave a lot and they did a great job of including us in the ceremony. Of course it wasn’t exactly like being there, but it was a hell of a lot better than seeing a few pictures three days later. When my kids were born, our option to do something similar was a $30,000 video conferencing system. You could fly in on the Concorde for less. And my brother in law would have needed a compatible systems as well. Through the wonders of Moore’s Law and the kindness of the bandwidth gods, now we can be anywhere in the world at any time. Now a Bris is not something you need (or even want) to see via a higher fidelity telepresence type environment. But seeing the entire family gathered, and being able to participate ourselves from Atlanta, was amazing. And that’s why the world is getting to be a smaller place every day. Of course I don’t do much video, because Rich and Adrian know what I look like (pretty as that is) and I’d rather not everybody see my 6-day stubble and bunny slippers (my usual work attire). But the technology is invaluable for connecting with those you like (and perhaps especially those you don’t like), when a phone call seems a bit 2-dimensional. Whether Apple’s FaceTime commercials bring a tear to your eye or not, you can’t disregard the experience. Video conferencing is going to happen, and I saw why on Monday. -Mike Photo credits: “It’s a Small World!” originally uploaded by Thomas Hawk Incite 4 U Pen testing obsolete? Hardly… Val Smith laid out some bait regarding whether pen testing is rapidly becoming obsolete. I guess that depends on how you define pen testing. The traditional unsophisticated run of Core or Metasploit with a bunch of glorified monkeys to check the compliance boxes is actually alive and well. PCI will ensure that for years to come. But that clearly not-so-useful practice will become more automated and cheaper, like every other competitive commodity function. But Val’s point at the end is that pen testing is evolving and needs to provide organizations with “a new type of service which tests their infrastructures and security postures in a different way”. That I agree with. There will always be a role for sophisticated white hats to try to break stuff. Maybe we stop calling that pen testing, which is fine by me. As long as you keep trying to break your stuff, call it whatever you want. – MR Don’t hack me, bro! Mocana made news this week when they announced they hacked into Internet TV set top boxes. I don’t think anyone is really surprised by this. The entire set top box / TV as Internet market is the poster boy for feature advancement land grab, with companies furiously vying for a share of Internet TV audiences. But really, who wants to worry about security when all you want is frackin’ TV! Can’t we all just get along? Well, no, not really. I am willing to bet that any security measure beyond a password and some rudimentary session-based encryption never came up in the product design meetings. “Winning the market” is about features, and the winner can clean up the mess later. Or at least that is the attitude I see. But these devices are stripped-down computers. And they use standard networking protocols. In most cases with reduced-footprint variants of standard operating systems. And it’s now attached to your home network. To me, Mocana is just pointing out the obvious, which is that these freakin’ things lack basic security. And it probably did not take anything more than a MitM attack to intercept the credit card, but I am willing to bet they are susceptible to injection as well. Granted, Mocana sells security products to help developers and designers secure these devices, so their PR is self-serving (of course), but this whole segment needs a wake-up call. – AL The name of the game? Reduce scope! I did a customer advisory board meeting for a client last year, and one of the attendees mentioned his specific goal was to reduce his PCI in-scope devices to zero. Right, he wanted to transition all protected data (and the associated processes) to external service providers and make PCI their problem. Certainly a noble goal, but not sure how realistic that is for most organizations. Clearly the trend is towards higher segmentation

As we discussed in our first Mobile Device Security post (I can haz your mobile), supporting smartphones isn’t really an choice. You aren’t going to tell your CEO or any other exec 5-6 pay grades above you that they can’t use their iPad to access the deal documents on that multi-billion dollar acquisition. You know it’s much easier to read an iPad on the can, than to lug the laptop around when taking care of business, right? If you are like most security professionals, your first instinct is to blurt out a resounding no, when presented with a request to connect an Android phone to your network. But your instincts are wrong. That wasn’t a question. It was an order – or soon will be. So your best bet is to practice the deep breathing exercises your meditation guru suggested. Once you’ve gotten your pulse back to a manageable 130, then you can and must have a constructive discussion about what resources are needed on the smartphone and why. User Profiles Are Your Friend The (sometimes fatal) mistake we see most often is treating every user as equivalent to every other user with the same device. This leads to providing the same level of access, regardless of who the user is. Allow us to suggest an alternative: profile users based on what they need to get, define 3-4 user types, and build your policies based on what they need, not what devices they have. For instance, you might have three user types: Executive: These folks can crush you with a stroke of their pen. Okay – a pen is old school. How about a click of their mouse? These people get what they want because saying no is not an option. They should be configured for email and document access, with a VPN client so they can access the corporate network (from the can). Connected Users: There will be another group of users who might have compromising pictures of the executives. Or maybe they actually provide tangible value to your organization. Either way, these folks need access, but probably not to everything. Design the policy to give them only what they need, and nothing more. Everyone else: If a person doesn’t fit into either of the other two buckets, then you give them access, but not enough that they can hurt themselves (or you). That means email, but probably not VPN access to the corporate network. These buckets are just examples – you’ll need to go through the use cases for each type of job function and see what levels of access make sense for your organization. Yes, but… As we mentioned above, your first instinct is likely to say ‘no’ when asked to support smartphones. But let’s tune the verbiage a bit and say “Yes, but” instead. After this easy mantra, go into all the reasons why it’s a bad idea for the user to have smartphone access to the organization’s sensitive stuff. You aren’t telling them no, but you are trying to convince them it’s a bad idea. But let’s acknowledge the truth: you’ll lose and the requestor will get access. The goal of this exercise isn’t necessarily to win the argument (though being able to block someone’s every so often access is good for your self-esteem), but instead to get folks put into the right user profile buckets. Everyone wants access to everything. But we know that’s a bad idea, so success is really more about how many users (as a percentage of all smartphone users) have limited access. That number will vary based on organization, but if it approaches 0% you need to practice “yes, but” a lot more. Cover Your Hind Section The last suggestion we’ll make relative to process is to ensure that you have documented the risks of supporting these devices. It’s critical to understand that our job as security professionals isn’t to stop business from happening – it’s to provide information to the decision makers so they can make rational, educated decisions. That means you need to inform them of the risks of whatever action they are going to take and push them to acknowledge the risk. If you fail to do this, you’ll be the one thrown out of the car at high speed when something goes wrong. Without ensuring clearly, and in writing, that everyone understands all the things that can go wrong by taking a particular action; you’ll end up in the proverbial creek without a paddle. Acknowledge that you won’t like all the decisions. Your job is to protect information and that requires reducing risk. Every company needs to take risks to continue to execute on their business plans. These two goals are diametrically opposed, but at the end of the day, it’s not our job to decide what risks make sense for your business. It’s our job to make sure everyone is clear on what those risks are, and enforce the decisions. As helpful as it is to put users in specific profiles, there are still a number of things you can do technically to protect your organization from the iPocalypse. As we wrap up this series, we’ll go through a few and provide ideas for how to protect your smartphone wielding employees from themselves. Share:

In New Data for New Attacks we discussed why there is usually too much data early in the process. Then we talked about leveraging the right data to alert and trigger the investigative process. But once the incident response process kicks in too much data is rarely the problem, so now let’s dig deeper into the most useful data for the initial stages of incident response. At this early stage, when we don’t yet know what we are dealing with, it’s all about triaging the problem. That usually means confirming the issue with additional data sources and helping to isolate the root cause. We assume that at this stage of investigation a relatively unsophisticated analyst is doing the work. So these investigation patterns can and should be somewhat standard and based on common tools. At this point the analyst is trying to figure out what is being attacked, how the attack is happening, how many devices are involved, and ultimately whether (and what kind of) escalation is required. Once you understand the general concept behind the attack, you can dig a lot deeper with cool forensics tools. But at this point we are trying to figure out where to dig. The best way to stage this discussion is to focus on the initial alert and then what kinds of data would validate the issue and provide the what, how, and how many answers we need at this stage. There are plenty of places we might see the first alert, so let’s go through each in turn. Network If one of your network alerts fires, what then? It becomes all about triangulating the data to pinpoint what devices are in play and what the attack is doing. This kind of process isn’t comprehensive, but should represent the kinds of additional data you’d look for and why. Attack path: The first thing you’ll do is check out the network map and figure out if there is a geographic or segment focus to the network alerts. Basically you are trying to figure out what is under attack and how. Is this a targeted attack, where only specific addresses are generating the funky network traffic? Or is it reconnaissance that may indicate some kind of worm proliferating? Or is it command and control traffic, which might indicate zombies or persistent attackers? Device events/logs/configurations: Once we know what IP addresses are in play, we can dig into those specific devices and figure out what is happening and/or what changed. At this stage of investigation we are looking for obvious stuff. New accounts or executables, or configuration changes, are typical indications of some kind of issue with the device. For the sake of both automation and integrity, this data tends to be centrally stored in one or more system management platforms (SIEM, CMDB, Endpoint Protection Platform, Database Activity Monitor, etc.). Egress path and data: Finally, we want to figure out what information is leaving your network and (presumably) going into the hands of the bad guys, and how. While we aren’t concerned with a full analysis of every line item, we want a general sense of what’s headed out the door and an understanding of how it’s being exfiltrated. Endpoint The endpoint may alert first if it’s some kind of drive-by download or targeted social engineering attack. You also can have this kind of activity in the event of a mobile device doing something bad outside your network, then connecting to your internal network and wreaking havoc. Endpoint logs/configurations: Once you receive an alert that there is something funky happening on an endpoint, the first thing you do is investigate the device to figure out what’s happening. You are looking for new executables on the device or a configuration change that indicates a compromise. Network traffic: Another place to look when you get an endpoint alert is the network traffic originating from and terminating on the device. Analyzing that traffic can give you an idea of what is being targeted. Is it a back-end data store? Is it other devices? How and where is the device is getting instructions? Also be aware of exfiltration activities, which indicate not only a successful compromise, but also a breach. The objective is to profile the attack and understand the objective and tactics. Application targets: Likewise, if it’s obvious a back-end datastore is being targeted, you can look at the transaction stream to decipher what the objective is and how widely has the attack spread. You also need to understand the target to figure out whether and how remediation should occur. Upper Layers If the first indication of an attack happens at the application layer (including databases, application servers, DLP, etc.) – which happens more and more, due to the nature of application-oriented attacks – then it’s about quickly understanding the degree of compromise and watching for data loss. Network traffic: Application attacks are often all about stealing data, so at the network layer you are looking primarily for signs of exfiltration. Secondarily, understanding the attack path will help discover which devices are compromised, and understand short and longer term remediation options. Application changes Is your application functioning normally? Or is the bad guy inserting malware on pages to compromise your customers? While you won’t perform a full application assessment at this point, you need to look for key indicators of the bad guy’s activities that might not show up through network monitoring. Device events/logs/configurations: As with the other scenarios, understanding to what degree the devices involved in the application stack are compromised is important for damage assessment. Content monitors: Given the focus of most application attacks on data theft, you’ll want to consult your content monitors (DLP, as well as outbound web and email filters) to gauge whether the attack has compromised data and to what degree. This information is critical for determining the amount of escalation required. Incident Playbook Obviously there are infinite combinations of data you can look at to figure out what is going on (and

Yesterday I got involved in an interesting Twitter discussion with Jeremiah Grossman, Chris Eng, Chris Wysopal, and Shrdlu that was inspired by Shrdlu’s post on application security over at Layer8. I sort of suck at 140 character responses, so I figured a blog post was in order. The essence of our discussion was that in organizations with a mature SDLC (security development lifecycle), you shouldn’t need to prove that a vulnerability is exploitable. Once detected, it should be slotted for repair and prioritized based on available information. While I think very few organizations are this mature, I can’t argue with that position (taken by Wysopal). In a mature program you will know what parts of your application the code affects, what potential data is exposed, and even the possible exploitability. You know the data flow, ingress/egress paths, code dependencies, and all the other little things that add up to exploitability. These flaws are more likely to be discovered during code assessment than a vulnerability scan. And biggest of all, you don’t need to prove every vulnerability to management and developers. But I don’t think this, in any way, obviates the value of penetration testing to determine exploitability. First we need to recognize that – especially with web applications – the line between a vulnerability assessment and penetration test is an artificial construct created to assuage the fears of the market in the early days of VA. Assessment and penetration testing are on continuum, and the boundary is a squishy matter of depth, rather than a hard line with clear demarcation. Effectively, every vulnerability scan is the early stage of a (potential) penetration test. And while this difference may be more distinct for a platform, where you check something like patch level, it’s even more vague for a web application, where the mere act of scanning custom code often involves some level of exploitation techniques. I’m no pen tester, but this is one area where I’ve spent reasonable time getting my hands dirty – using various free and commercial tools against both test and (my own) production systems. I’ve even screwed up the Securosis site by misconfiguring my tool and accidentally changing site functionality during what should have been a “safe” scan. I see what we call a vulnerability scan as merely the first, incomplete step of a longer and more involved process. In some cases the scan provides enough information to make an appropriate risk decision, while in others we need to go deeper to determine the full impact of the issue. But here’s the clincher – the more information you have on your environment, the less depth you need to make this decision. The greater your ability to analyze the available variables to determine risk exposure, the less you need to actually test exploitability. This all presumes some sort of ideal state, which is why I don’t ever see the value of penetration testing declining significantly. I think even in a mature organization we will only ever have sufficient information to make exploitation testing unnecessary for a small number of our applications. It isn’t merely a matter of cost or tools, but an effect of normal human behavior and attention spans. Additionally, we cannot analyze all the third party code in our environment to the same degree as our own code. As we described a bit in our Building a Web Application Security Program paper, these are all interlocking pieces of the puzzle. I don’t see any of these as in competition in the long term – once we have the maturity and resources to acquire and use these techniques and tools together. Code analysis and penetration testing are complementary techniques that provide different data to secure our applications. Sometimes we need one or the other, and often we need both. Share:

Ah yes, 2011 is here. A new year, which means it’s time to put into action all of those wonderful plans you’ve been percolating over the holidays. Oh, you don’t have plans, besides getting through the day, that is? I get that. The truth is things aren’t likely to be better in 2011 – probably not even tolerable. But we persevere because that’s what we do, although a lot of folks (including AndyITGuy, among others) continue talking burnout risk. And that means we have to refocus. A while back I did a presentation called The Pursuit of Security Happyness. It was my thoughts on how to maintain your sanity while the world continues to burn down around you. But that was about you. If you drew the short straw, you may be in some kind of management position. That means you are not only responsible for your own happiness, but have a bunch of other folks looking to you for inspiration and guidance. I know, you probably don’t feel like much of a role model, but you drew the short straw, remember? Own it, and work at it. The fact remains that most security folks aren’t very good at managing. Neither their security program (what the Pragmatic CSO is about), nor their people. With it being a new year and all, maybe it’s a good idea to start thinking about your management skills as well. Where do you start? I’m glad you asked… I stumbled across a post from Richard Bejtlich over the break, which starts with a discussion about how Steve Jobs builds teams and why they are successful. Yes, you need good people. Yes, the bulk of your time must be spent finding these people. But that’s not interesting. What’s interesting is making the mission exciting. Smart talented folks can work anywhere. As a manager, you need to get them excited about working with you and solving the problems you need to solve. LonerVamp highlighted a great quote at the bottom of Bejtlich’s post: Real IT/security talent will work where they make a difference, not where they reduce costs, “align w/business,” or serve other lame ends. So that’s what you need to focus on. To be clear, someone has to align with business. Someone also has to reduce costs and serve all those lame ends, which was LonerVamp’s point. Unfortunately as a manager, that is likely you. Your job as a manager is to give your people the opportunity to be successful. It means dealing with the stuff they shouldn’t have to. That means making sure they understand the goal and getting them excited about it. Right, you need to be a Security Tony Robbins, and motivate your folks to continue jumping into the meat grinder every day. And all of this is easier said than done. But remember, it’s a new year. If you can’t get excited about what you do now, maybe you need to check out these tips on making your resume kick ass. Share: