Research

Here in the US, today is Martin Luther King, Jr. Day. For many this means a day off. For others it’s a continued call to arms to right the injustice we see. For me, it’s a reminder. A reminder of how one person’s efforts can make a difference against unsurmountable odds. How passion, focus, and a refusal to fail can change the world. Not overnight and not without setbacks, personal sacrifices, and a lot of angst. But it can be done. We in the security world seem to forget that all the time. Today started like most other days. I checked my email. I looked at my Twitter feed and, surprisingly enough, a bunch of folks were bitching about PCI and stupid assessors and all sorts of other negativity. Pretty much like every other day. I shut down my Twitter client and thought a bit about why I do what I do, even though it seems to make no difference most days. It’s because it’s the good fight and the mere fact that it’s hard doesn’t mean we shouldn’t continue pressing forward. Rich summed it up very well a few weeks ago in his Get Over It post. Human nature isn’t going to change. So we’ll always be swimming upstream. Deal with it. Or find something else to do. And to be clear, what we do isn’t hard. Fighting for civil rights is hard. Overcoming oppression and abject poverty and terrible disease is hard. Always keep that in mind. Always. The Boss is constantly telling me there is no grey in my world. Right. Wrong. Nothing in between. And pushing to educate our kids about what they should and should not do online is right. Pushing to help our organizations understand the risks of all their business plans is right. Trying to get senior management to appreciate security, even though it makes their jobs harder at times, is right. Doing nothing is wrong. If you are reading this blog, then you are likely very fortunate. With resources and education and opportunities that billions of people in this world don’t have. So yes, what we do is hard. But it’s not that hard. On this day, where the US celebrates one of its true giants, a man who gave everything for what he thought was right, take a few minutes and re-dedicate yourself to fighting the good fight. Because it’s the right thing to do. Image credit: “Martin Luther King, Jr.” originally uploaded by U.S. Embassy New Delhi Share:

The RSA Conference is just around the corner, and you know what that means. Pain. Pain in your head, and likely a sick feeling in your stomach. All induced by an inability to restrain your consumption when surrounded by oodles of fellow security geeks and free drinks. You know what? We’re here for you. Once again, with the help of our friends at ThreatPost and Schwartz Communications, we will be holding our Disaster Recovery Breakfast to cure what ales ya (or ails you, but I think my version is more accurate). This year the breakfast will be Thursday morning from 8-11 at Jillian’s in the Metreon. It’s an open door – come and leave as you want. We’ll have food, beverages, and assorted recovery items to ease your day (non-prescription only). No marketing, no spin, just a quiet place to relax and have muddled conversations. It sure beats trying to scream at the person next to you at some corporate party with pounding music and, for the most part, a bunch of other dudes. Invite is below. To help us estimate numbers please RSVP to rsvp@securosis.com. Share:

Apparently I got out of New York just in time. The entire eastern seaboard got “Snowmageddon II, the Blanketing” a few hours after I left. Despite a four-legged return flight, I did actually make it back to Phoenix. And Phoenix was just about the only place in the US where it was not snowing, as I heard there was snow in 48 states simultaneously. I was in NYC for the National Retail Federation’s 100th anniversary show. It was my first. I was happy to be invited, as my wife and her family have been in retail for decades, and I was eager to speak at a retail show. And this was the retail show. I have listened to my family about retail security for 20 years, and it used to be that their only security challenge was shrinkage. Now they face just about every security problem imaginable, as they leverage technology in every facet of operations. Supply chain, RFID, POS, BI systems, CRM, inventory management, and web interfaces are all at risk. On the panel were Robert McMillion of RSA and Peter Engert of Rooms to Go. We were worried about filling an hour and a half slot, and doubly anxious about whether anyone would show up to talk about security on a Sunday morning. But the turnout was excellent, with a little over 150 people, and we ended up running long. Peter provided a pragmatic view of security challenges in retail, and Robert provided a survey of security technologies retail merchants should consider. It was no surprise that most of the questions from the audience were on tokenization and removal of credit cards. I get the feeling that every merchant who can get rid of credit cards – those who have tied the credit card numbers to their database primary keys – will explore tokenization. Oddly enough, I ended up talking with tons of people at the hotel and its bar, more than I did at the conference itself. People were happy to be there. I guess they they were there for the entire week of the show, and very chatty. Lots of marketing people interested in talking about security, which surprised me. And they had heard about tokenization and wanted to know more. My prodding questions about POS and card swipe readers – basically: when will you upgrade them so they are actually secure – fell on deaf ears. Win some, lose some, but I think it’s healthy that data security is a topic of interest in the retail space. One last note: as you can probably tell, the number of blog entries is down this week. That’s because we are working on the Cloud Security Alliance Training Course. And fitting both the stuff you need to know and the stuff you need to pass the certification test into one day is quite a challenge. Like all things Securosis, we are applying our transparent research model to this effort as well! So we ask that you please provide feedback or ask questions about any content that does not make sense. I advise against asking for answers to the certification test – Rich will give you some. The wrong ones, but you’ll get them. Regardless, we’ll post the outlines over the next few days. Check it out! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s DR post on Vodafone’s breach. Rich quoted in the Wall Street Journal. Adrian at the National Retail Federation Show, telling the audience they suck at security. Did I say that? Mike, talkin’ to Shimmy about Dell, brand damage, and the Security Bloggers meet-up Favorite Securosis Posts Rich: The Data Breach Triangle. We didn’t push out a lot of content this week so I’m highlighting an older post. In line with Gunnar’s post on where we spend, I find it interesting that the vast majority of our security spending focuses on ingress… which in many ways is the toughest problem to solve. Mike Rothman: What do you want to see in the first CSA Training Course? Yes, we have a murder’s row of trainers. And you should go. But first tell us what needs to be in the training… David Mortman: What Do You Want to See in the First Cloud Security Alliance Training Course? Gunnar Peterson: What Do You Want to See in the First Cloud Security Alliance Training Course? Sensing a theme here? Adrian Lane: Mobile Device Security: 5 Tactics to Protect Those Buggers. Other Securosis Posts Funding Security and Playing God. Incite 1/12/2011: Trapped. Favorite Outside Posts Rich: Gunnar’s back of the envelope. Okay, I almost didn’t pick this one because I wish he wrote it for us. But although the numbers aren’t perfect, it’s hard to argue with the conclusion. Mike Rothman: Top 10 Things Your Log Managment Vendor Won’t Tell You. Clearly there is a difference between what you hear from a vendor and what they mean. This explains it (sort of)… David Mortman: Incomplete Thought: Why Security Doesn’t Scale…Yet.. Damn you @Beaker! I had a section on this very need in the upcoming CSA training. And, of course, you said it far better…. Adrian Lane: Can’t decide between this simple explanation of the different types of cloud databases, and this pragmatic look at cloud threats. Gunnar Peterson: Application Security Conundrum by Jeremiah Grossman, with honorable mention to The Virtues of Monitoring. 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 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 China CERT: We Missed Report On SCADA Hole . SAP buying SECUDE. TSA Worker Gets 2 Years for Planting

I was reading shrdlu’s post on Connecting the risk dots over on the Layer 8 blog. I thought the point of contention was how to measure cost savings. Going back and reading the comments, that’s not it at all. “we can still show favorable cost reduction by spotting problems and fixing early.” You have to PROVE it’s a problem first … This is why “fixing it now vs fixing it sooner” is a flawed argument. The premise is that you MUST fix, and that’s what executives aren’t buying. We have to make the logic work better. She’s right. Executives are not buying in, but that’s because they don’t want to. They don’t want to comply with SOX or pay their taxes either, but they do it anyway. If your executives don’t want to pay for security testing, use a judo move and tell them you agree; but the next time the company builds software, do it without QA. Tell your management team that they have to PROVE there is a problem first. Seriously. I call this the “quality architect conundrum”. It’s so named because a certain CEO (who shall remain nameless) raised this same argument every time I tried to hire an architect who made more than minimum wage. My argument was “This person is better, and we are going to get better code, a better product, and happier customers. So he is worth the additional salary.” He would say “Prove it.” Uh, yeah. You can’t win this argument, so don’t head down that path. Follow my reasoning for a moment. For this scenario I play God. And as God, I know that the two architectural candidates for software design are both capable of completing the project I need done. But I also know that during the course of the development process, Architect A will make two mistakes, and Architect B will make 8. They are both going to make mistakes, but how many and how badly will vary. Some mistakes will be fixed in design, some will be spotted and addressed during coding, and some will be found during QA. One will probably be with us forever because we did not see the limitation early enough and we be stuck. So as God I know which architect would get the job done with fewer problems, resulting in less work and less time wasted. But then again, I’m God. You’re not. You can’t prove one choice will cause fewer problems before they occur. What we discover, being God or otherwise, is that from design through the release cycles a) there will be bugs, and b) there will be security issues. Sorry, it’s not optional. If you have to prove that there is a problem so you can fund security you are already toast. You build it in as a requirement. Do we really need to prove Deming was right again? It has been demonstrated many times, with quantifyable metrics, that finding issues earlier in the product development cycle reduces at large costs to an organization. I have demonstrated, within my own development teams, that fixing a bug found by a customer is an order of magnitude more expensive than finding and fixing it in house. While I have see diminishing returns on some types of security testing investments, and some investments work out better than others, I found no discernable difference in the cost of security bugs vs. those having to do with quality or reliability. Failing deliberately, in order to justify action later, is still failure. Share:

It leaked a bit over Twitter, but we are pretty excited that we hooked up with the Cloud Security Alliance to develop their first training courses. Better yet, we’re allowed to talk about it and solicit your input. We are currently building two courses for the CSA to support their Cloud Computing Security Knowledge (CCSK) certification (both of which will be licensed out to training organizations). The first is a one day CCSK Enhanced class which we will be be delivering the Sunday before RSA. This includes the basics of cloud computing security, aligned with the CSA Guidance and ENISA Rick documents, plus some hands-on practice and material beyond the basics. The second class is the CCSK Review, which will be a 3-hour course optimized for online delivery and to prep you for the CCSK exam. We don’t want to merely teach to the book, so we are structuring the course to cover all the material in a way that makes more sense for training. Here is our current module outline with the person responsible and their Twitter handle in case you want to send them ideas: Introduction and Cloud Architectures. (Domain 1; Mike Rothman; @securityincite) Creating and securing a public cloud instance. (Domains 7 & 8; David Mortman; @mortman) Securing public cloud data. (Domains 5 & 11; Adrian Lane; @adrianlane) Securing cloud users and applications (Domains 10 & 12; Gunnar Peterson; @oneraindrop) Managing cloud computing security and risk (Domains 6 & 9 and parts of 2, 3, & 4; James Arlen; @myrcurial) Creating and securing a private cloud (Domain 13; Dave Lewis; @gattaca) The entire class is being built around a fictional case study to provide context and structure, especially for the hands-on portions. We are looking at: Set up instances on AWS and/or RackSpace with a basic CMS stack (probably on EC2 free, with Joomla). Set basic instance security. Encrypt cloud data (possibly the free demo of the Trend EBS encryption service). Something with federation/OAuth. Risk/threat modeling exercise. Set up a private cloud (vCloud or Eucalyptus) Keep in mind this is a one-day class so these will be very scripted and quick – there’s only so much we can cover. I will start pushing out some of the module outlines in our Complete feed (our Highlights RSS feed still has everything due to a platform bug – you only need to know that if you visit the site). We can’t put everything out there since this is a commercial class, but here’s your chance to influence the training. Also remember that we are deep into the project already with a very tight deadline to deliver the pilot class at RSA. Thanks Share:

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: