Good Programming Practices vs. Rugged Development

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

Read Post

Friday Summary: February 4, 2011

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

Read Post

You Made Your Bed, Now Sleep in It

Twitter exploded last night with news that the self-proclaimed world’s #1 hacker’s email and Twitter accounts were compromised. Personally, the amount of time that good people spend feeding that troll annoys me. Which is why I’m not mentioning his name. Why give him any more SEO points for acting poorly? Since the beginning of time there have been charlatans, shysters, and frauds; this guy is no different. Major media outlets are too dumb and lazy to do the work required to vet their experts, so they respond to his consistent PR efforts. Whatever. But let’s deal with the situation at hand because it’s important. First off, if you bait a lion, you shouldn’t be surprised when you get eaten. Tell me you were surprised when Roy got mauled by his white tiger. I was more surprised it took that long. In other words, live by the sword, die by the sword. And clearly that is the case here. Now there are 4gb of email and other sensitive files in the wild, and this guy’s closet will be opened for all to see. And there are skeletons in there. To be clear, this is wrong. The attackers are breaking the law, but it’s hard to feel bad for the victim. His sophomoric threats, frivolous lawsuits, and intimidation games probably worked OK in the schoolyard, but in the real world – not so much. It’s your bed, now you get to sleep in it. Second, if you know you are a target, why would you leave a huge amount of sensitive documents in an email store on a publicly accessible server? I read a Tweet that said his email was at GoDaddy. Really? And isn’t the first rule of email that it’s not a file store? I know we all probably violate that dictum from time to time, but to have financial records, account numbers, and legal filings in your email box? Come on, now! Basically, I suspect there is stuff there that could put our victim in the big house for a long time. Again, you made the bed, now sleep in it. We take ridiculous security precautions for a 3-person company. It’s actually a huge pain in the ass. And we are fully cognizant that at some point we will likely be breached. Crap, if it can happen to Kaminsky it can happen to us. So we don’t do stupid things. Too often. And that really is the lesson here. Everyone can be breached, even the world’s #1 hacker. Share:

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.