Check out agile admin James Wickett’s talk from DeliveryConf last month on adding security into your continuous software delivery pipeline!
Tag Archives: InfoSec
Lean Security
James and I have been talking lately about the conjunction of Lean and Security. The InfoSec world is changing rapidly, and just as DevOps has incorporated Lean techniques into the systems world, we feel that security has a lot to gain from doing the same.
We did a 20 minute talk on the subject at RSA, you can check out the slides and/or watch the video:
While we were there we were interviewed by Derek Weeks. Read his blog post with a transcript of the interview, and/or watch the interview video!
Back here in Austin, I did an hour-long extended version of the talk for the local OWASP chapter. Here’s a blog writeup from Kate Brew, and the slides and video:
We’ll be writing more about it here, but we wanted to get a content dump out to those who want it!
AppSec USA 2012 Is Here (in Austin)!
AppSec USA 2012, the big OWASP security convention, is here in Austin this year! And the agile admin’s own @wickett is coordinating it.
“Why do I care if I’m not a security wonk,” you ask? Well, guess what, the security world is waking up and smelling the coffee – this isn’t like security conventions were even just a couple years ago. There’s a Cloud track and a Rugged DevOps track.
We have like 20 people going from Bazaarvoice. It’s two days, Thursday and Friday (yes, tomorrow – I don’t know why James didn’t post this earlier, sorry) and just $500. So it’s cheap and low impact.
And who’s speaking? Well, how about Douglas Crockford, inventor of JSON? And Gene Kim, author of Visible Ops? That’s not the usual infosec crowd, is it? Also Michael Howard from Microsoft, Josh Corman from Akamai, a trio of Twitter engineers, Nick Galbreath (formerly of Etsy), Jason Chan from Netflix, Brendan Eich from Mozilla… This is a star-studded techie event that you want to be at!
I’ll be there and will report in…
Filed under Conferences, DevOps, Security
Rugged Software Manifesto: An Interview With Dan Cornell
I had a chance to talk with Dan Cornell from the Open Web Application Security Project (OWASP) and the Denim Group. Dan has over 13 years of experience in development and is one of the founders at the Denim Group, a company that does security consulting day in and day out for all types of clients. Dan wrote Sprajax, a security analyzer for AJAX applications, and is the chair of the OWASP Global Membership Committee.
While a lot of us work with security, it is usually in addition to other dev or ops responsibilities and isn’t our sole focus. However, Dan Cornell and his company are in the weeds of app security daily. It is a pleasure to have him on the agile admin blog and we are chatting with him on his thoughts on the Rugged Software Manifesto. We ran across this manifesto at the Lonestar Application Security Conference (LASCON) and heard it referred to by both OWASP board members and Department of Homeland Security types so we thought we should look it up, and it seemed interesting. So here’s Dan’s thoughts on the subject.
@wickett: Hi Dan, welcome to the agile admin blog. Our first question for you is, what do we mean by Rugged Software?
@danielcornell: I think of software that is going to run as intended, regardless of the conditions it encounters when it is deployed. A big part of this is security, but that isn’t the only thing. You also have to take into account reliability, survivability and a variety of other ‘-ity’ properties. The Internet, and networks in general, are dangerous places where you need to be conscious of both malicious actors as well as other, unintentional adverse conditions such as service outages, congestion, untrained users making mistakes and so on. Rugged Software is software that is designed and built to deal with these conditions – foreseen or not.
@wickett: When we have talked about Rugged Software with developers, we get a fair amount of pushback and hear statements like, “Rugged Software isn’t really real and that it is just a PR play.” Some developers and engineers we;ve talked to say that it lacks depth, clarity and process, but I wonder if these engineers have even seen the original Agile Manifesto. In my mind, I look back at the original Agile Manifesto and I am equally under-whelmed by it as I imagine they are by the Rugged Software Manifesto. Do you see any parallels between the original Agile Manifesto and the Rugged Software Manifesto?
@danielcornell: The two biggest challenges I see for the Rugged Software movement are to provide a business justification for being Rugged to management and to answer the “so what?” question for developers. Dealing with the first will go a long way toward solving the second.
If you ask most executives and managers if they’d like their software to be Rugged they’ll likely give an answer somewhat along the lines of: “Sure I’d love to be ‘Rugged.’ And ‘Agile’ and ‘Pragmatic’ and whatever other buzzwords the industry has come up with lately. All that stuff is great but what I really want is to be on time and on budget and I want more features than our competitors.” Thinking about security and quality and performance and anything else comes later.
So this is an area where the Rugged movement needs to do a better job of explaining why Rugged makes good business sense and you run into the same challenges that information security folks have had making a business justification for security for years. Allowing an organization to avoid pain when the auditors or compliance folks come around is of value – but it often isn’t enough. Reducing downtime and disruption in the future because you have avoided a breach or outage is of value – but it often isn’t enough. David Rice has done some great thinking in this area in his book Geekonomics but, as an industry, I think we are still looking for the universal truth to be revealed that will make everyone sit up and take notice and I think we’re going to be waiting for a long time.
That said, some organizations have made the decision that this is an area that merits focus and when executives and managers make Rugged (or security or whatever) a priority then it is much easier to get the troops to fall in line. I’m reminded of a secure coding training class I ran recently for an ISV where the VP in charge of engineering stood up at the beginning of the class and said “This is a priority for us and the material in this class represents the base level of knowledge everyone is expected to have.” Then he sat in the entire two day class and at the end told his people “I hope you paid attention because you are going to be held accountable for knowing and implementing this material.” Wow! This was one of the best classes I taught in a long time; everyone showed up on time, paid attention, asked questions and so on. I’d love to think it is because I’m such a funny and engaging guy but what really made the difference is that the leadership demonstrated with actions that security is a priority. A similar model is always going to be the most effective way to drive Rugged into an organization. Bottom-up, grass roots efforts are valuable because they raise awareness and help to identify like-minded potential champions, but to drive adoption at scale management needs to feel that this is a priority.
Speaking of priorities, I think this is an area where the Agile Manifesto style can provide some guidance. The Rugged Manifesto is a great call to arms, but it is very self-referential: “I am Rugged… and more importantly my code is Rugged” And so on. If you look at the Agile Manifesto it calls out trade offs: “Individuals and interactions over processes and tools,” for example. It accepts that processes and tools have merit, but chooses to value individuals and interactions more. Acknowledging that decisions must be made and providing guidance on why one is superior to another is a stronger basis for a conversation and this is going to be key. Right now those trade-offs are presented as “Prefer code without vulnerabilities over code with vulnerabilities” Duh! Who wouldn’t want that? But the real question is what are they going to have to give up to get it.
@wickett: Over the next five years, do you see the Rugged Software Manifesto becoming a standard? Will we have Rugged development practices and be operating on a new paradigm for development or will it get lumped under Agile?
@danielcornell: Well the Rugged Software Manifesto is just that – a Manifesto. It isn’t a standard. And I don’t think we are ever going to see a standard for software development because “development” is too big a thing to be done in a standard way. You can’t expect folks building banking applications for East Coast financials to follow the same process as a couple of folks in a garage trying to build the next Facebook. What I hope is developed and adopted, however, are so-called “best practices” such as threat modeling, static analysis for quality and security, security code review, penetration testing and so on.
Also, Agile and Rugged are two separate movements. Agile is about creating customer-centric software in a flexible and timely manner and Rugged is about making software that doesn’t break. Their goals are not exclusive, but they’re also different.
@wickett: When thinking about Rugged Software, what are practical steps that individual developers can adopt into their current practices whether they use Agile, Waterfall, or other development methodology?
@danielcornell: Well first I think it is important to note that individual developers can have a positive impact on their own code, but this is going to be largely ineffective if the rest of the development team doesn’t share the same goals. The “weakest link in the chain” analogy comes to mind. That said…
Threat Modeling is a practice that can be adopted into any development methodology. There are lots of resources out there that explain how to use it to improve the security of complicated systems and it can also be used for the greater purpose of Rugged software by asking questions such as “what if this data flow stop flowing” or “what if this data store becomes unavailable” This is best done by the team as a whole but it is also a practice that an individual developer can use on their own portions of a system.
Penetration testing and resiliency testing are other practices that teams can implement to help test the Ruggedness of their applications and systems.
@wickett: What open source tools do you think should fit into the tool chain for a rugged developer? What about for a rugged operations/sysadmin?
@danielcornell: Static analysis tools like FindBugs, PMD and FxCop can be really valuable. For dynamic testing a web proxy like WebScarab can be really useful to testing how software is going to respond to unexpected inputs.
On the operations/sysadmin thing a critical Rugged practice is to proactively monitor systems in order to anticipate problems. From the standpoint, you should be instrumenting systems and not just tracking failures. When an HTTP server goes down it is often too late to prevent an outage and that isn’t very Rugged. Instead you also need to be tracking disk and processor usage, traffic and response time trends and so on in order to be able to anticipate problems. Fortunately there are a lot of open source tools available for DIY folks as well as SaaS offerings that can make this sort of instrumentation less of a hill to climb that it was in the past.
@wickett: We appreciate having time with Dan and hearing from an industry leader on Rugged Software. To keep up Dan on the interweb, you can follow him on twitter or check out his blog.
Filed under Security
The Rise of the Security Industry
In late 2007 Bruce Schneier, the internationally renowned security technologist and author, wrote an article for IEEE Security & Privacy. The ominously named article: The Death of the Security Industry predicted the future of the security industry or lack thereof. In it he predicts that we would treat security as merely a utility like we use water and power today. The future is one where “large IT departments don’t really want to deal with network security. They want to fly airplanes, produce pharmaceuticals, manage financial accounts, or just focus on their core business.”
Schneier closes with, “[a]s IT fades into the background and becomes just another utility, users will simply expect it to work. The details of how it works won’t matter.”
Looking back 3 years and having the luxury of hindsight, it is understandable to see why he thought the security industry would become a utility. In part, it has become true. Utility billing is the rage for infrastructure (hello cloud computing) and more and more people are viewing the network as a commodity. Bandwidth has increased in performance and decreased in cost. Continually people are outsourcing pieces of their infrastructure and non-critical IT services to vendors or to offshore employees.
But there are three reasons why I disagree with the The Death of the Security Industry and I believe we are actually going to see a renaissance of the security industry over the next decade.
1. Data is valuable. We can’t think of IT as merely the computers and network resources we use. We need to put the ‘I’ back in IT and remember why we play this game in the first place. Information. Protecting the information (data) will be crucial over the long haul. Organizations do not care about new firewalls or identity management as a primary goal, however they do care about their data. Data is king. Organizations that succeed will be ones that master navigating a new marketplace that values sharing while keeping their competitive edge by safe-guarding and protecting their critical data.
2. Security is a timeless profession. When God gave Adam and Eve the boot from the Garden of Eden, what did he do next? He used a security guard to keep them out of the Garden for good. Security has been practiced as long as people have been people. As long as you have something worth protecting (see ‘data is valuable’ in point 1) you will need resources to protect it. Our valuable data is being transferred, accessed and modified on computing devices and will need to be protected. If people can’t trust that their data is safe then they will not be our customers. The CIA security triad (Confidentiality, Integrity, and Availability) needs to remain in tact for consumers to trust organizations with their data and if that data has any value to the organization, it will be need to be protected.
3. Stuxnet. This could be called the dawn of a new age of hacking. Gone are the days of teenagers running port scans from their garages. Be ready to start seeing hackers using sophisticated techniques that simultaneously attack multiple vectors to gain access on their targets. I am not going to spread FUD (Fear Uncertainty and Doubt) around, but I believe that Stuxnet is just the beginning.
In addition to how Stuxnet was executed, it is just as interesting to see what was attacked. This next decade will prove to be a change in the type of targets attacked. In the 80’s it was all about hacking phones and more physical targets, the 90’s were the days of the port-scanning and Microsoft Windows hacking, the last decade has primarily focused on web and application data. With Stuxnet, we are seeing the revitalization of hacking where it is returning to its roots of hacking targets that are physical in nature such as SCADA systems that control a building’s temperature systems. The magazine 2600 has been publishing a series on SCADA hacking over the last 18 months. What makes it even more interesting is that almost every device you buy these days has a web interface on it, so never fear, the last 10 years spent hacking websites will come in real handy when looking at hacking control systems.
In closing, I think we are a long way off from seeing the death of the security industry. As our data becomes more valuable, the more we will need to secure. Data is on the rise and with it comes the need for security. Additionally as more and more of our world is controlled with computers, the targets become more and more interesting. Be ready for the rise of the security industry.
Let me know what you think on twitter: @wickett
the agile admin 