Research

There is a caste system in technology. It’s an engineering caste system, or at least that’s what I call it. A feeling of superiority developers have over their QA, IT, product management, and release management brethren. Software developers at every firm I have ever worked for – large and small – share a condescending view of their co-workers when it comes to technology. They are at the top of the totem pole, and act as if their efforts are the most important. It starts in college, where software programs are more competitive to get in and require far more rigorous curricula. It is fostered by the mindset of programmers, who approach their profession more like religion. It’s not a 9-5 day job, and most 20-something developers I have worked with put in longer hours and put in more time into self education than any other profession I have ever seen. They create something from nothing every day; and with software, anything is possible. The mindset is reinforced by pay scales and recognition when products are delivered. Their technical accumen runs far deeper than the other groups and they don’t respect those without it. This relationship between different professions is reinforced when problems arise, as developers are the ones explaining how things work and advising those around them. It’s the engineering team that writes the trickier test cases, and the engineers who comes up with the best product ideas. Heck, of the last four organization I have run, to solve serious IT issues I had to assign members of the engineering team to debug and fix. They are technology rocks stars and prima donnas. Right or wrong, good or bad, this attitude is commonplace. Why do I bring this up? Reviewing the marketing and sales collateral from several security vendors who are applying their IT marketing angles to software developers, I see a lot of approaches that will not work. When it comes to understanding buying centers, those who have traditionally sold into IT don’t get the developer mindset. They approach sales and marketing as if the two were interchangeable, but they are not. The things developers consider important are not the same things the rest of IT considers important. It is unlikely your “IT Champion” can cross-pollinate your ideas to the development team – both because your champion is likely seen as an outsider by the developers and due to internal tension between different groups. Development sets development requirements. White box test tools? Web application assessments? WAF? Even pen testing? These all need different buyers, with a different mind set and requirements than the buyers of other IT kit – especially compared to network operations gear. The product and the value proposition needs to work in the development context. Most sales and marketing teams want to target the top – the CIO – and work their way down from there. That works for most of IT, but not with developers who have their own set of requirements over and above business requirements, and often neither fear nor respect upper management. They are far less tolerant of marketing-speak and BS and much more focused on getting things done easily, so you had better show value quickly or you’re wasting time. UI, workflow, integration, and API options need to be more flexible. When it comes to application security, it’s a developer’s world, so adjust or be ignored. Share:

During the e10+ event Monday at the RSA Conference, Rich and Mike moderated a panel on Optimizing Your Security Program. One of the contested topics was how to position security to upper management. Every CIO and CISO falls into the trap of having to say ‘No’ to some new idea that occurs to executive management, and then take blame for being “Negative Nancy”, “Dr. No”, “The Knight who says NEE”, or some collection of the Seven Dirty Words. I was surprised that so little has changed, as these were exactly the same problems I had a dozen years ago. While security threats were far simpler and fewer then, so was acknowledgement of the need for security. I guess it’s human nature that we still fall into the same traps. For example, I remember the principal VC of one of the many start-ups I worked at, stating we needed to take credit cards – I responded that it was too risky given our (total lack of) site security. He looked at me as though I was stupid, insubordinate, and insensitive to customer requirements. I remain convinced it was one of the reasons I was one of the first people let go during a series of cost cutting RIFs. At the brokerage there was a bi-polar attitude, that 9 days out of 10 I needed to get the sales staff what they need to do their jobs, and make things as easy as possible so the sales conversations were aided rather than hindered by technology. Day ten was a hair-on-fire security exercise because some broker was printing out the entire database to bring to a competitor. On the tenth day you will be asked by the CEO, “What are you doing to protect my data?” The correct answer is not, “making it super easy for people to get access,” or “exactly what you told me to.” As a CIO your priroity is service, but you are responsible for security. I managed accordingly, or at least I started out that way. I figured I had the authority to nix projects that compromised data security. I felt it was my responsibility, as champion of security, to halt new projects until they addressed data and compliance issues. Outsiders felt security turned simple ideas into complex – and costly – projects. In reality, though most new ideas were not fleshed out, and failed to account for total build costs – much less the cost to clean up messes down the road. Still, complexity was “my fault”. This resulted in complaints, mid-level mangers trying to bypass me altogether, and bosses realigning my bonus incentives based on project completion and satisfaction of IT users. Running IT services for popularity is dangerous, and results in bizarre feature-based prioritization of improvements, with user satisfaction hinging almost purely on system stability. You add shiny toys of no consequence and you make sure things are reliable – no more. I only recommend this if you want to ‘earn’ some short term bonuses and promotions, then quickly move to your next employer. If you want to succeed in the job for more than a couple consecutive quarters, avoid being a feature firewall, and avoid having your merit judged on convenience and system uptime. Features and new ideas are more likely to come from outside your organization than inside, and no one else wants security, so you have to field these challenges. Trying to spin security as a business enabler is great conceptually but rarely works in the real world. I used three approaches to avoid being the bad guy for advocating security: The Security Porcupine: When I started working with sales people, I learned many sales techniques. One of the best tactics I ever learned was the ‘Porcupine’ strategy from Tom Hopkins, which I bastardized a bit to help with IT projects. In essence, you don’t catch a porcupine when it’s thrown at you – instead you deflect it. Ask the originator how they feel the problem should be addressed. “What a great idea! How would you like to handle [security/compliance/auditng] requirements we must meet?” This is a choice-based strategy. It gives the person who had the idea some responsibility by recognizing their idea carries a security burden; they can then help scale back their idea, or accept security controls as part of the plan. Either way, security becomes a facet of their project. The Hidden Security Project: If it’s your responsibility to form the IT deployment plan, take responsibility for it and build security in. Weave security into the project plan, subtly or otherwise, such that it is difficult to discern core function from security or operations. Costs and functions are bundled, and a detailed presentation makes it look like you have invested time into understanding how to get the project done. Present the plan and let the executive team decide if the investment is worth it. If it passes, you have both budget and executive buy-in. If not, the work you put into the plan saved you from disaster down the road. The Gauntlet: Accept the proposal and enter a “requirements phase”. As the project undergoes scruitiny from your team, raise security as an outstanding question. Also make sure internal compliance, security, and external auditors review the plan. It’s likely someone else will have the same security concerns you do – in addition to compliance and procedural issues you never thought of. If the idea is truly worthy, it will pass these tests. Either way, don’t fight it head-on. Most ideas die in the process, and nobody gets egg on their face when the initial state of euphoria passes over to critical reasoning. It’s a transparent pass-the-buck ruse in smaller organizations, but can harden and flesh out good ideas in larger firms. I hate to advocate shenanigans, but business is business, and people will turn you into road pizza if you don’t protect yourself. Share:

There’s nothing like a late-night phone call saying, “I think your email has been hacked,” to drop a security professional over the edge. My wife called me during the RSA Conference to tell me this, because some emails she got from me were duplicates that refused to be deleted. Weirdness like that always makes me question my security, and when I found the WiFi still enabled on my phone, I had my yearly conference ‘Oh $#(!’ moment early. I consider it a BH/DefCon and RSA tradition, as it happens every year: seething paranoia. And this year the HBGary hack kept my paranoia amped up. The good news is that when I am in this state of mind I find mistakes. It not only makes me suspicious of my own work – I assume I screwed up, and that critical mindset helped me discover a couple flaws. A missed setting on a router, and leaving WiFi on when I went to SF. And there was another mistake understanding how a 3rd party product worked, so I needed to rethink my approach to data security on that as well. Then I start thinking: if they got access to this email account, what would that enable an attacker to do? I don’t sleep for the rest of the night, thinking about different possibilities. Sleep deprivation makes it difficult to maintain this degree of focus long-term, but I always harbor the feeling that something is wrong. The bad news is that this state of mind does not go well with interpersonal relationships. Especially in the workplace. Suspicious, distrust, and critical are great traits when looking at source code trying to find security flaws. They are not so great when talking to the IT team about the new system crossover they will be doing in 3 days (despite, of course, being several weeks behind on pre-migration tasks). Stressed out of their minds trying to make sure the servers won’t crash, nobody wants you to point out all they ways they failed to address security – and all the (time consuming) remediation they really should/must perform. We take it out on those not tasked with security, because anyone who does not hold the security bar as high as we do must be an idiot. And God help those poor phone solicitors trying to sell IPS to me after RSA because they somehow managed to scan my conference badge – I now feel the need to educate them on all 99 ways their product sucks and how they don’t understand the threats. Do you have to have a crappy attitude to be effective in this job? Do we need to maintain a state of partial paranoia? I am unable to tell if I simply had this type of personality, which lead me into security; or if the profession built up my the glass is half-empty, cracked, and about to be stolen at any moment, attitude. I’d stop to smell the roses but I might suffer an alergic reaction, and I am certain those thorns would draw blood. Sometimes I feel like security professionals have become the NSA of the private sector – trust no one. We have gotten so tired of leading a charge no-one follows that we have begun to shoot each other. Camaraderie from shared experiences brings us together, but a sense of distrust and disrespect cause more infighting than within any other profession I can think of. We have become a small corporate counterculture without a cool theme song. Share:

The Friday summary is our chance to talk about whatever, and this week I am going to do just that. This week’s introduction has nothing to do with security, so skip it if you are offended by such things. I am a fan of basketball – despite being too slow, too short, and too encumbered by gravity to play well. Occasionally I still follow my ‘local’ Golden State Warriors despite their playoff-less futility for something like 19 of the last 20 years. Not like I know much about how to play the game, but I like watching it when I can. Since moving to Phoenix over 8 years ago it’s tough to follow, but friends were talking last summer about the amazing rookie season performance of Stephen Curry and I was intrigued. I Googled him to find out what was going on and found all the normal Bay Area sports blogs plus a few independents – little more than random guys talking baskeball related nonesense. But one of them – feltbot.com – was different. After following the blog for a while an amazing thing happened: I noticed I could not stomach most of the mainstream media coverage of Warriors basketball. It not only changed my opinion on sports blogs, but cemented in my mind what I like about blogs in general – to the point that it’s making me rethink my own posts. The SF Bay Area has some great journalists, but it also has a number of people with great stature who lack talent, or the impetus to use their talent. These Bay Area personalities offer snapshots of local sports teams and lots of opinions, but very little analysis. They get lots of air but little substance. Feltbot – whoever he is – offers plenty of opinions, just like every other Bay Area sports blogger. And he has lots of biases, but they are in the open, such as being a Don Nelson fanboi. But his opnions are totally contrary to what I was reading and hearing on the radio. And he calls out everyone, from announcers to journalist when he thinks they are off the mark. What got me hooked was him going into great detail on why why – including lots of analysis and many specific examples to back up his assertions. You read one mainstream sports blog that says one thing, and another guy who says exactly the opposite, and then goes into great detail as to why. And over the course of a basketball season, what seemed like outlandish statements week one were dead on target by season’s end. This blog is embarrasing many of the local media folk, and downright eviscerating a few of them – making them look like clueless hacks. I started to realize how bad most of the other Bay Area sports blogs were (are); they provide minimal coverage and really poor analysis. Over time I have come to recognize the formulaic approach of the other major media personalities. You realize that most writers are not looking to analyze players, the coach, or the game – they are just looking for an inflammatory angle. Feltbot’s stuff is so much better that the other blogs I have run across that it makes me feel cheated. It’s like reading those late-career James Patterson novels where he is only looking for an emotional hook rather than trying to tell a decent story. For me, feltbot put into focus what I like to see in blogs – good analysis. Examples that illustrate the ideas. It helps a basketball noob like me understand the game. And a little drama is a good thing to stir up debate, but in excess it’s just clumsy shtick. Sometimes it takes getting outside security to remind me what’s important, so I’ll try to keep that in mind when I blog here. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading post: DAM Market Observation. Mort cited for talking about cloud security at Bsides. Rich and Mike covered on the Tripwire blog. Rich quoted on SearchSecurity. Favorite Securosis Posts Rich: Always Assume. This is a post I did a while back on how I think about threat/risk modeling. In a post HBGary world, I think it’s worth a re-read. Mike Rothman: What No One Is Saying about That Big HIPAA Fine. Sometimes you just need to scratch your head. Adrian Lane: FireStarter: Risk Metrics Are Crap. Yeah, it was vague in places and intentionally incendiary, but it got the debate going. And the comments rock! Other Securosis Posts On Science Projects. Random Thoughts on Securing Applications in the Cloud. Network Security in the Age of Any Computing: the Risks. Incite 3/2/2011: Agent Provocateur. React Faster and Better: Index. React Faster and Better: Piecing It Together. Favorite Outside Posts Rich: Numbers Good. Jeremiah’s been doing some awesome work on web stats for a while now, and this continues the trend. Mike Rothman: Post-theft/loss Response & Recovery With Evernote. We need an IR plan for home as well. Bob does a good job of describing one way to make filing claims a lot easier. Adrian Lane: Network Security Management-A Snapshot. Really nice overview by Shimmy! 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. Security + Agile = FAIL Presentation. Top News and Posts Alleged WikiLeaker could face death penalty. SMS trojan author pleads guilty. NIST SHA-3 Status Report. Robert Graham Predicts Thunderbolt’s an Open Gateway. Malware infects more than 50 Android apps. Thoughts on Quitting Security. Gh0stMarket operators sentenced. 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 Alex Hutton,

How do you secure data in the cloud? The answer is “it depends”. What type of cloud are you talking about – IaaS, PaaS, or SaaS? Public or Private? What services or applications are you running? What data do you want to protect? Following up on the things I learned at RSA, one statement I heard makes sense now. Specifically, a couple weeks ago Chris Hoff surprised me when, talking about data security in the cloud, he tweeted: Really people need to be thinking more about app-level encryption. Statements like that normally make the information-centric security proponent in me smile with glee. But this time I did not get his point. Lots of different models of the cloud, and lots of ways to protect data, so why the emphatic statement? He answered the question during the Cloudiquantanomidatumcon presentation. Chris asked “How do you secure data in two virtual machines running in the cloud?” The standard answer: PKI and SSL. Data at rest and data in motion are covered. With that model in your head, it does not look too complex. But during the presentation, especially in an IaaS context, you begin to realize that this is a problem as you scale to many virtual machines with many users and dispersed infrastructure bits and pieces. As you start to multiply virtual machines and add users, you not only create a management problem, but also lose the context of which users should be able to access the data. Encryption at the app layer keeps data secure both at rest and in motion, should reduce the key management burden, and helps address data usage security. App layer encryption has just about the same level of complexity at two VMs; but its complexity scales up much more gradually as you expand the application across multiple servers, databases, storage devices, and whatnot. So Chris convinced me that application encryption is the way to scale, and this aligns with the research paper Rich and I produced on Database Encryption, but for slightly different reasons. I can’t possibly cover all the nuances of this discusion in a short post, and this is big picture stuff. And honestly it’s a model that theoretically makes a lot of sense, but then again so does DRM, and production deployments of that technology are rare as hen’s teeth. Hopefully this will make sense before you find yourself virtually knee deep in servers. Share:

I was surprised at the negative tweets and blog posts after the RSA show this year, many by the security professionals at the core of this industry. I have been to RSA most years since 1997. This year, discontent and snarkiness seemed to be running high. “There is nothing new.” “There is no innovation.” “The vendors are all lying.” “These products don’t work as advertised.” “I have seen this presentation before.” “That attack won’t work in ‘the real world’.” I saw nobody excited about the concept of winning a car – what’s up with that!?! You know it’s bad when attendees complain about booth babes – booth babes! – and then go to the Barracuda party. You know who you are. This year, like most years, I learned a lot. I got a great introduction to mobile OS security fron Zach Lanier (Quine) over dinner. I learned a lot about Amazon EC2 and related seurity issues. I learned that a vendor may have lied to me about their key manager. Jeremiah Grossman’s presentation got me thinking about how I can improve my Agile SDL presentation. I learned that CIOs and CISOs are still struggling with the same challenges I did 10 years ago; and falling victim to the same role, organizational, and communication pitfalls. Chris Hoff answered a question on why app level encryption will probably scale better when protecting data in VMs. Talking to attendees, I learned there are a couple technologies that are still giant mysteries to average IT professionals. I learned that far fewer developers have worked within an Agile process than I expected. And by watching security and non-security people, I am still learning what makes a good analyst. Beyond what I learned, there is the whole personal side of it: meeting friends and getting some of the inside stories about security breaches and vendors. I got to meet, face to face, a couple of the people I criticized here, and was relieved that they appreciated my comments and did not take them personally. I got to meet people I admire and respect, including Michael Howard of Microsoft and Ivan Ristic of Qualys. I got to talk Rugged software with a very diverse group of people. But perhaps the biggest single event, and the one I have the most fun at every year for the last four, is the Security Bloggers Awards – where else in the world am I going to attend a professional gathering and see 50 friends in the same room at the same time? I recognize that only about 35% of this is due to sessions and RSA sanctioned events; but all the other training sessions, parties, and people would not be in San Francisco at one time if it was not for the conference. The sheer gravity of the RSA Conference pulls all these people and events together. If you’re not getting something out of the conference, if you are burned out and not learning, look in the mirror. Not every year can you be hit on the head with a career-altering revelation, but there are too many smart people in attendance for you not to come away with lots of new ideas and reshaped perceptions. I am overjoyed that I can still get excited about this profession after 15 years, because there is always something new to learn. Share:

When we say application security, for we generally mean web application security. We probably could have cheated and simply reposted last year’s guide to application security and still been close. Yes, application security is still a nascent market. Last year the focus was anti-exploitation to prevent code injection attacks, and the value provided by integrating assessment and web application firewall technologies. While the threats remain the same, there are some new twists which deserve attention. What We Expect to See Code Review Services: Strapping security onto the network layer and hoping it catches your application vulnerabilities is a band-aid at best, and companies that produce applications know this. With HP’s acquisition of Fortify a few months ago, Microsoft’s announcement of Attack Surface Analyzer, and IBM’s acquisition of Ounce Labs in 2009, it’s clear that the world’s major software providers know this as well. And they are looking to capitalize on the movement. Third party source code review services are on the rise, and most web development teams now use either white-box or black-box testing in their certification processes. “Building security in” is an increasingly common mantra for development teams, and there is tremendous opportunity to sell security products and services into this nascent market. Most development teams are just now learning about secure coding techniques, threat modeling, and how to build unit-based security tests to run alongside their functional tests. We expect to see many vendors offering tools, education, and services that foster secure code everywhere from design to post-deployment. Not just pre-and-post deployment checkers and firewalls, but security offerings for every single step in the development lifecycle. Buyer Shift: “What?” you say. I am not selling to the IT manager? Not here you are not. IT plays a part, but the buying center is shifting to the development team for web application security technologies. And that’s a very different conversation, with a much different set of requirements and use cases the vendor needs to address. OWASP As the Guiding Light: Publicity concerning application security issues is growing. OWASP — the Open Web Application Security Project — provides a Top 10 list of the most common threats to applications. And it’s a good rundown of sneaky, underhanded tricks attackers use to compromise web applications for fun and profit. Even better, it’s backed by measurable statistics so it’s not all conjecture and innuendo. This list is driving many companies’ marketing campaigns, and the alignment of their service offerings as well. How well any given vendor protects applications from these threats is open for debate, but the fact that they are responding to the most common threat vectors we see today is very good news. Web application vulnerabilities represent a significant threat to organizations as web services are an integral part of business operations, and the push for more SaaS and cloud based services means attackers have an increasing number of potential targets. As if you haven’t had enough cloud on a stick, up next are our thoughts on endpoint security, and then virtualization and cloud security in the RSA Guide. I know, you can’t wait. Share:

Global Threats. APT. Botnets. Infected Web Pages. Grannies with shotguns. We expect to see anything and everything it takes for vendors to get your attention, including never before seen awards and security metrics. Some ask “Why the hype?” The value of content security — both inbound filtering to prevent unwanted garbage from coming into the network, as well as detection of unwanted activity like surfing for porn or sending company secrets to your cousin as investment advice — is proven. All the major players and most mid-tier providers have closed the major holes in their products, provide unified management for all functions, and offer some type of SaaS service. The technology works. The problem is that the segment is both mature and saturated. To earn a new customer, a vendor must steal one from a competitor. Growing revenue means convincing customers they need a new service. It is increasingly difficult to differentiate the top tier from the mid-tier players, so that noise you hear is vendors trying to find an edge. For the most part, the vendors offer quality services at a price point that continues to drop with reduced cost cloud and SaaS based offerings. But you can’t blame the vendors from trying to “one up” the competition in a crowded market. What We Expect to See There are three areas of interest at the show for content security: It’s Raining Devices: One thing you are going to learn wandering around Moscone is how the cloud protects those endpoint devices. Yep! The Content Security Cloud protects the endpoint. Isn’t that what cloud security is all about? Well, no, actually, but you are will hear about it. Those services that run on your iPhone/Droid/Blackberry are theoretically just as susceptible to attack as what’s on your desktop or laptop. Supposedly. That’s the vendor argument, but attacks against mobile devices are more likely to target lower layers of the infrastructure — but don’t worry, vendors won’t let facts ruin a good story. In most cases the vendor is offering exactly the same services they already provide for your laptop/workstation to protect from the same threats on new devices. But hey, it’s ‘the cloud’, so it must be good! More DLP: Yes, content security providers offer Data Loss Prevention. In most cases, it’s just the subset of DLP needed to detect data exfiltration. And regular expression checking for outbound documents and web requests is good enough to address the majority of content leakage problems, so this is a good addition for most customers. By and large we hear from satisfied customers who implement a dozen or so content policies for specific violations they are interested in detecting, and find the analysis techniques sufficient. Deployments of this type are far less daunting than a full featured soup-to-nuts DLP platform, so we hear far more success stories and less about shelfware. Users Are Employees Too: Scams, fraud, and phishing attacks continue to hammer those uninterested in security, and the IT managers who support them. The content security vendors know that nothing else matters to some users besides getting to their Facebook pages on their lunch hour. It also means these users are unusually susceptible to phishing attacks, drive-by malware, and account compromises. In and of themselves these attacks are fairly low-yield and low-damage. But a compromised computer on a corporate network acts as a launching pad for all sorts of network mayhem. Content security providers can no longer claim the “Insider Threat” is your biggest security concern, but they will let IT managers know they help mitigate damages from stupid human tricks. Next up in the hit parade is Data Security. OK, repeat after me: WikiLeaks, WikiLeaks, WikiLeaks – and you’ll start to get a feel for this year’s RSA Conference rally cry. Share:

I had a long chat with Josh Corman yesterday afternoon about Rugged, especially as it applies to software development. I know this will be a continuing topic at the RSA conference, and we are both looking forward to a series of brainstorming sessions on the subject. One aspect that intrigues both of us is the overlap between Agile and Rugged as conceptual frameworks for guding developer decisions. I though this was important enough to blog up prior to the conference. The discussion went something like this: Agile – as a concept – is successful because when the principles behind the Agile Manifesto are put into practice, they make software development easier and faster. Agile development – embodied as one of many different process enhancements – is successful because they promote Agile principles. When creating Rugged, mirroring Agile Manifesto was a great approach because both strive to adjust development’s approach to creating software. But the Agile Manifesto illustrates – through its 12 principles – how you should prioritize preferences and make tradeoffs when molding software. Rugged has yet to define the principles that, when put into practice, promote Rugged software. Rugged is missing embodiments – examples to guide practitioners – that describe and promote Rugged principles. Rugged denotes a problem set (software is fragile, insecure, and feature-focused to the exclusion of all else) but lacks principles and a roadmap for fixing it. That’s the bad part, and the gist of my Twitter rant earlier this week. The good news is that the overlap between the two concepts provides plenty of examples of what Rugged could be. The more I think about it, the more I think the parallels between Agile and Rugged are important and serve as an example of how to approach Rugged development. There is sufficient overlap that several of the Agile principles can be directly adopted by Rugged with no loss of meaning or intent. Specifically, stealing from the Agile Principles: Welcoming changing requirements, even late in development …: Threats evolve rapidly, as do use cases and deployment models (Cloud? Anyone?). The fact that new security issues pop up like whack-a-moles is no different than new feature requests in web application development. The agility to respond to new requests and reprioritize on customer importance is no different that being agile enough to respond to risks. This principle applies equally well to Rugged as to Agile. Working software is the primary measure of progress: If your software does not compile, or is filled with logic errors, development efforts have not been totally successful. If your code is filled with security bugs, your software has variable functionality, then your development efforts have not been totally successful. When it comes to secure code development, I look at security as just another vector to manage on. It’s one of many factors that must be accounted for during the development process. Security is not your only goal, and usually not even the most important goal, but something important to account for. You can choose to ignore it, but if so there will likely be some major issue down the road. We are at that uncomfortable junction in the history of software development where we are seeing some firms have businesses disrupted by failing to manage risks posed by new code. Ruggedness should be a metric for progress. Continuous attention to technical excellence and good design enhances agility: I do threat modelling when building new software. I do it after the architecture phase and sometime during the design phase, because threat modelling finds weaknesses in my design choices. Sometimes they are logic flaws, sometimes communication protocol flaws, and sometimes it’s simply that the platform I was considering does support adequate security. Regardless, examining code with a jaundiced eye – looking for issues before they become serious problems – is all part of the design process. The scrutiny enhances product quality and Ruggedness. I have avoided problems before they became serious, because they were exposed during design, and those problems were easier to fix than ones I found later. That is only one example of the overlap. Build projects around motivated individuals: Coders are competitive. Developers have egos. Most developers want to write quality code, and to be recognized as experts who pay attention to detail. Most I have worked with are highly motivated to practice, to learn, and to get better. When there is a coding standard, they work hard to make sure their code meets it. They don’t want the code they checked in to crash the nightly build because everyone on the team will hear about it. If Ruggedness is part of the coding standard, and security checks are part of daily regression tests, there is no reason to expect the development team to do anything other than raise their game and meet the challenge. Simplicity – the art of maximizing the amount of work done – is essential: Developers are creative. Agile as a concept is intended to allow developers to think of creative solutions. Group discussions and open dialog, combined with rapid prototyping proofs of concept, all help find simple solutions to complex problems. Security problems fall to the same blade if you allow them to be addressed in the same way. Unfortunately much of what I am proposing here is a heck of a lot easier when building new code, as opposed to retrofitting old code. I have lugged the burden of legacy software many times, and the restrictions imposed by some old glob of misbehaving garbage crushes inspiration and ingenuity. Bubble gum and duct tape are fun up to a point, but sooner or later it becomes just fixing someone else’s crap over and over again. With new code I contend that Rugged is simply good programming practices – and if incorporated efficiently it will make software designers, coders, and quality assurance teams better. To some of you I am simply playing security jazz, this is all BS, and it really does not help you get your jobs

My wife says to me, “I seem to be getting your junk mail. Somebody just sent me Data Security Quiz results.” I have no idea what she means, so she forwarded me the email from the National Information Security Assocation (NISA). I confess that I had never heard of this organization before, and I really don’t know what they do. Apparently they quizzed a number of real estate agents and brokers around the country to find out how much they knew about data security. The results were emailed as a way of educating real estate professionals at large. Color me shocked. Actually, I thought the questions were pretty good to be asking for sales people. The Q&A was as follows: According to industry standard practices, when is it safe to leave sensitive client information in your car (either in electronic form, such as a laptop or in paper form)? Answer: d) Never. Which tool is most important once a network breach has been discovered? Answer: c) Access Log For most workplace computers when is it possible to be infected with malicious software? Answer: a) Anytime the computer is on. If I only collect client data for a short sale processing company, I am not responsible for data leaks? Answer: False What are the only actions that can guaranty the security of client data? Answer: c) There is no way to guaranty data security. What is the one sure method to determine if your computer contains malicious software? Answer: b) There is no way to be 100 percent sure. Question three actually cracked me up because it is so true! I think there is a little bit of FUD going on here to get people to attend a seminar, because the email talks about blended threats and Stuxnet. I know real estate agents are pretty pissed about the state of the economy, but I am pretty sure plutonium enrichment is not a general concern. Regardless, it is very interesting to see how much security awareness training and security bullitens are being distributed to real estate professionals. Like Rich’s mention a few weeks ago that the owner of the local coffee shop was aware of PCI-DSS. The times they are a-changin’. One final note: It appears we have SOLD OUT the Cloud Security Training course we are offering February 13th. If you are still interested, let us know and we will see if we can find a bigger room. Probably not, but we will see what we can do. Given the interest in the material, we are looking at providing more classes in the coming months so it helps us if you let us know if you are interested in cloud security certification. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading article on Database Security in the Cloud. First in a series. Securosis Mentioned in PF newsletter. Adrian’s podcast on Agile Development, Security Fail for RSA. More NRF quotes from Adrian on security in the retail vertical. Rich quoted on 10 Risks in Public Cloud Computing. Favorite Securosis Posts Mike Rothman: Good Programming Practices vs. Rugged Development. We can always learn from similar initiatives and try not to make the same mistakes. Interesting post here from Adrian comparing Rugged to Agile. Adrian Lane: You Made Your Bed, Now Sleep in It. Ego and bravado have a funny way of coming back to crush security pros. Have I mentioned I suck lately? Other Securosis Posts Incite 2/2/2011: The End of Anonymity. Favorite Outside Posts Mike Rothman: Everyone has a plan until they get hit. I’m glad Gunnar is our team. Great quote from Tyson. Great post. Adrian Lane: Why terror alert codes never made sense. Actually every airport I have been to has been ‘Orange’ for three years. Too bad there are no free market forces to punish this type of stupidity. 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. 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. Security + Agile = FAIL Presentation. Top News and Posts Microsoft accuses Google of Clickjacking. Abusing HTTP Status Codes to Expose Private Information. Plentyofhack, er, Plentyoffish Hack. Skimmers That Never Touch ATM. Mark Anderson says China’s IP Theft Unprecedented. Egypt shuts down their Internet. NRO to announce IPV6. The NRO might want to have someone pen test their site as I am getting error codes straight from the database, but that’s a different subject. 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 Joshua Corman, in response to Good Programming Practices vs. Rugged Development. @securityninja Rugged is a Value. A characteristic. An Attribute. A Quality. A State. Rugged in its simplest sense is an affirmative, non-security-executive desirable. Security is a negative – a Cost/Tax and usually an inhibitor to what a CIO wants. Rugged encapsulates things like: Availability Survivability Supportability Longevity Security* Scalability …that the CIO already wants. For your eCommerce, do you want a flimsy Hosting Site? or a Rugged Hosting site? Communities like OWASP can help developers to affect more Rugged outcomes. Jeff is involved in Rugged. Rugged is on the overlooked People level more heavily than on the process and tech level. We have a lot of great tools and technology and frameworks (sure we could use more and better ones). What’s most been lacking is Mainstream awareness and demand for the value of Rugged. In my 11/12 months, I’ve seen the most traction for Rugged on those buying software. on Demand. If we can drive sufficient Demand, Supply will often follow. I’m still looking to connect with you 1 on 1. For