the agile admin

So… DevOps.  DevOps vs NoOps has been making the rounds lately. At Bazaarvoice we are spawning a bunch of decentralized teams not using that nasty centralized ops team, but wanting to do it all themselves.  This led me to contemplate how to express the things that Operations does in a way that turns them into developer requirements?

Because to be honest a lot of our communication in the Ops world is incestuous.  If one were to point a developer (or worse, a product manager) at the venerable infrastructures.org site, they’d immediately poop themselves and flee.  It’s a laundry list of crap for neckbeards, but spends no time on “why do you want this?” “What value will this bring to your customer?”

So for the “NoOps” crowd who want to do ops themselves – what’s an effective way to state these needs?  I took previous work – ideas from the pretty comprehensive but waterfally “Systems Development Framework” Peco and I did for NI, Chris from Bazaarvoice’s existing DevOps work – and here’s a cut.  I’d love feedback. The goal is to have a small discrete set of areas (5-7), with a small discrete set (5-7) of “most important” items – most importantly, stated in a way so that people understand that these aren’t “annoying things some ops guy wants me to do instead of writing 3l33t code” but instead stated as they should be, customer facing requirements like any other.  They could then be each broken into subsidiary more specific user stories (probably a whole lot of them, to be honest) but these could stand in as “epics” or “pillars” for making your Web thing work right.

Service Delivery Best Practices

Availability

• I will make my service highly available, so that customers can use it constantly without issues
• I will know about any problems with my service’s delivery to customers
• I can restore my service quickly from any disaster or loss
• I can make my data resistant to corruption from runtime issues
• I will test my service under routine disruption to make it rugged and understand its failure modes

Performance

• I know how all parts of the product perform and can measure performance against a customer SLA
• I can run my application and its data globally, to serve our global customer base
• I will test my application’s performance and I know my app’s limitations before it reaches them

Support

• I will make my application supportable by the entire organization now and in the future
• I know what every user hitting my service did
• I know who has access to my code and data and release mechanism and what they did
• I can account for all my servers, apps, users, and data
• I can determine the root cause of issues with my service quickly
• I can predict the costs and requirements of my service ahead of time enough that it is never a limiter
• I will understand the communication needs of customers and the organization and will make them aware of all upgrades and downtime
• I can handle incidents large and small with my services effectively

Security

• I will make every service secure
• I understand Web application vulnerabilities and will design and code my services to not be subject to them
• I will test my services to be able to prove to customers that they are secure
• I will make my data appropriately private and secure against theft and tampering
• I will understand the requirements of security auditors and expectations of customers regarding the security of our services

Deployment

• I can get code to production quickly and safely
• I can deploy code in the middle of the day with no downtime or customer impact
• I can pilot functionality to limited sets of users
• I will make it easy for other teams to develop apps integrated with mine

Also to capture that everyone starting out can’t and shouldn’t do all of this… We struggled over whether these were “Goals” or “Best Practices” or what… On the one hand you should only put in e.g. “as much security as you need” but on the other hand there’s value in understanding the optimal condition.

Austin is such a great place to be a techie.

• The Austin Cloud User Group (I help run it) meets every third Tuesday evening, and we’ve ben having 50+ people come in to check out some awesome stuff.  Next meeting Feb 21 on Puppet, hosted by Pervasive.
• The Agile Austin DevOps SIG meets fourth Wednesdays, we had our meeting today and had about 20 attendees, hosted by CA/Hyperformix. I also help run that one.
• The Austin Big Data User Group is back meeting – next one is tomorrow night! Hosted by Bazaarvoice.
• The Austin OWASP chapter is one of the biggest and most active in the country, and also meets monthly, hosted by National Instruments. Fellow Agile Admin James Wickett helps run that group.
• The Cloud Security Alliance, Austin chapter is just getting started but has a lot of momentum and we’re coordinating with them from the ACUG and OWASP sides. Their first meeting is tonight, come out!

There are others but those are my favorites and therefore the coolest by definition.

There’s also cool events coming up you should keep an eye out for.

• DevOpsDays Austin, Apr 2-3, hosted by National Instruments, and this’ll be big! Patrick Debois and the whole crew of DevOps illuminati will be here. Now taking sponsors and speakers! Register now!
• AppSec USA 2012, Oct 23-26 – Austin OWASP kicks so much ass with LASCON that the annual OWASP convention is coming here to Austin this year!
• South by Southwest Interactive, March 9-13 – quickly becoming theWeb conference in the flyover states . Lots of stuff happens during it, like:
  • Austin Cloud/DevOps party courtesy GeekAustin (ACUG is a community sponsor). March 10.
  • CloudCamp – Dave Nielsen will be bringing a CloudCamp to Austin again this year during SXSWi. Details TBD, sounding like Mar 11 maybe.
• The Cloud Security Alliance and ACUG are hoping to put together an Austin cloud conference, too. Maybe early 2013.

Fellow Agile Admin, James Wickett, just wrote an article for Control Engineering about cloud security. Cloud security is kinda funny, it’s the biggest FUD attractor and “concern” of folks who don’t really know how their on premise security works either.  Anyway, read the article! We’re putting some real security work into our cloud products at NI; can’t speak for others but…

In related news, the excellent Cloud Security Alliance is starting an Austin chapter! Go check it out. The CSA got a start by being an organization that actually issues effective guidance on cloud security instead of being another vendor-haven or FUD collector.

Also see my older LASCON 2010 presentation on “Why The Cloud Is More Secure Than Your Existing Systems” (now a year later, the trade rags are stealing that headline for their own spam…  Woot!)

As I’ve been involved with DevOps and its approach of blending development and operations staff together to create better products, I’ve started to see similar trends develop in the security space. I think there’s some informative parallels where both can learn from each other and perhaps avoid some pitfalls.

Here’s a recent article entitled “Agile: Most security guys are useless” that states the problem succinctly. In successful and agile orgs, the predominant mindset is that if you’re not touching the product, you are semi-useless overhead. And there’s some truth to that. When people are segregated into other “service” orgs – like operations or security – the us vs. them mindset predominates and strangles innovation in its crib.

The main initial drive of agile was to break down that wall between the devs and the “business”, but walls remain that need similar breaking down. With DevOps, operations organizations faced with this same problem are innovating new approaches; a collaborative approach with developers and operations staff working together on the product as part of the same team. It’s working great for those who are trying it, from the big Web shops like Facebook to the enterprise guys like us here at NI. The movement is gathering steam and it seems clear to those of us doing it this way that it’s going to be a successful and disruptive pattern for adopters.

But let’s not pat ourselves on the back too much just yet. We still have a lot of opportunity to screw it up. Let’s review an example from another area.

In the security world, there is a whole organization, OWASP (the Open Web Application Security Project) whose goal is to promote and enable application security. Security people and developers, working together!  Dev+Sec already exists! Or so the plan was.

However, recently there have been some “shots across the bow” in the OWASP community.  Read Security People vs Developers and especially OWASP: Has It Reached A Tipping Point? The latter is by Mark Curphey, who started OWASP. He basically says OWASP is becoming irrelevant because it’s leaving developers behind. It’s becoming about “security professionals” selling tools and there’s few developers to be found in the community any more.

And this is absolutely true.  We host the Austin OWASP chapter here at NI’s Austin campus, and two of the officers are NI employees. We make sure and invite NI developers to come to OWASP. Few do, at least not after the first couple times.  I asked some of the devs on our team why not, and here’s some answers I got.

• I want to leave sessions by saying, “I need to think about this the next time I code”. I leave sessions by saying, “that was cool, I can talk about this at a happy hour”. If I could do the former, I’d probably attend most/all the sessions.
• A lot of the sessions don’t seem business focused and it is hard to relate. Demos are nicer; but a lot of times they are so specific (for example: specific OS + specific Java Version + specific javascript library = hackable) that it’s not actionable.
• “Security people” think “developers” don’t know what they are doing and don’t care about security. Which to developers is offensive. We like to write secure applications; sometimes we just find the bugs too late….
• I’ve gone to, I think, 4 OWASP meetings.  Of those, I probably would only have recommended one of them to others – Michael Howard’s.  I think it helped that he was a well-known speaker and seemed to have a developer focus. So, well-known speakers, with a compelling and relevant subject..  Even then, the time has to be weighed against other priorities.  For example, today’s meeting sounds interesting, but not particularly relevant.  I’ll probably skip it.

In the end, the content at these meetings is more for security pros like pen testers, or for tool buyers in security or sysadmin groups. “How do I code more securely” is the alleged point of the group but frankly 90% of the activity is around scanners and crackers and all kinds if stuff that is fine but should be simple testing steps after the code’s written securely in the first place.

As a result there have been interesting ideas coming from the security community that are reminiscent of DevOps concepts. Pen tester @atdre did a talk here to the Austin OWASP chapter about how security testers engaging with agile teams “from the outside” are failing, and shouldn’t we instead embed them on the team as their “security buddy.” (I love that term.  Security buddy. I hate my “compliance auditor” without even meeting the poor bastard, but I like my security buddy already.) At the OWASP convention LASCON, Matt Tesauro delivered a great keynote similarly trying to refocus the group back on the core problem of developing secure software; in fact, they’re co-sponsoring a movement called “Rugged” that has a manifesto similar to the Agile Manifesto but is focused on security, availability, reliability, et cetera. (As a result it’s of interest to us sysadmin types, who are often saddled with somehow applying those attributes in production to someone else’s code…)

The DevOps community is already running the risk of “leaving the devs behind” too.  I love all my buddies at Opscode and DTO and Puppet Labs and Thoughtworks and all. But a lot of DevOps discussions have started to be completely sysadmin focused as well; a litany of tools you can use for provisioning or monitoring or CI. And that wouldn’t be so bad if there was a real in for developers – “Here’s how you as a developer interact with chef to deploy your code,” “Here’s how you make your code monitorable”. But those are often fringe discussions around the core content which often mainly warms the cockles of a UNIX sysadmin’s heart. Why do any of my devs want to see a presentation on how to install Puppet?  Well, that’s what they got at a recent Austin Cloud User Group meeting.

As a result, my devs have stopped coming to DevOps events.  When I ask them why, I get answers similar to the ones above for why they’re not attending OWASP events any more. They’re just not hearing anything that is actionable from the developer point of view. It’s not worth the two hours of their valuable time to come to something that’s not at all targeted at them.

And that’s eventually going to scuttle DevOps if we let it happen, just as it’ll scuttle OWASP if it continues there. The core value of agile is PEOPLE over processes and tools, COLLABORATION over negotiation. If you are leaving the collaboration behind and just focusing on tools, you will eventually fail, just in a more spectacular and automated fashion.

The focus at DevOpsDays US 2010 was great, it was all about culture, nothing about tools. But that culture talk hasn’t driven down to anything more actionable, so tools are just rising up to fill the gap.

In my talk at that DevOpsDay I likened these new tools and techniques to the introduction of the Minie ball to rifles during the Civil War. In that war, they adopted new tools and then retained their same old tactics, walking up close in lines designed for weapons with much shorter ranges and much lower accuracy – and the slaughter was profound.

All our new DevOps tools are great, but in the same way, if we don’t adapt our way of thinking to them, they will make our lives worse, not better, for all their vaunted efficiency. You can do the wrong thing en masse and more quickly. The slaughter will similarly be profound.

A sysadmin suddenly deciding to code his own tools isn’t really the heart of DevOps.  It’s fine and great, and I like seeing more tools created by domain experts. But the heart of DevOps, where you will really see the benefits in hard ROI, is developers and operations folks collaborating on real end-consumer products.

If you are doing anything DevOpsey, please think about “Why would a developer care about this?” How is it actionable to them, how does it make their lives easier?  I’m a sysadmin primarily, so I love stuff that makes my job easier, but I’ve learned over the years that when I can get our devs to leverage something, that’s when it really takes off and gives value.

The same thing applies to the people on the security side.  Why do we have this huge set of tools and techniques, of OWASP Top 10s and Live CDs and Metasploits and about a thousand wonderful little gadgets, but code is pretty much as shitty and insecure as it was 20 years ago? Because all those things try to solve the problem from the outside, instead of targeting the core of the matter, which is developers developing secure code in the first place.  And to do that, it’s more of a hearts-and-minds problem than a tools-and-processes problem.

That’s a core realization that operations folks, and security folks, and testing folks, and probably a bunch of other folks need to realize, deeply internalize, and let it change the way they look at the world and how they conduct their work.

I was just reading this interesting InfoWorld post on The Most Common Turf Wars in IT – very relevant to what we talk about around here. It’s mainly about stakeholders not properly integrated into the product/project/release planning process. Their most common turf wars are so true:

“Ops vs. Dev” – A cry for DevOps. One of the reasons we have this blog.

“Admin on Admin” – And a good bit of the challenge with that is that admins themselves are a bit grumpy by nature and need them a little “OpsOps.” Being chronically marginalized and given a vision of “contain costs!” is to blame, but it means we sysadmins have a little more personal-skills work to do in order to go from BOFH to team collaborator.

“Security vs Everyone” – Bringing security to the DevOps table can be challenging; if there’s one group more elitist and cynical than sysadmins, it’s security professionals. The job obviously requires a little bit of that mindset. But there’s some movement in the security community to understand the need for collaboration in a DevOps style.

“Management vs. Staff” – Well, that’s more of a question for the ages.

There are others, but these are definitely the “big four” in my experience.  What do y’all think?

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.

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

Recently I have been reading on OPSEC (operations security).  OPSEC, among many things, is a process for security critical information and reducing risk.  The 5 steps in the OPSEC process read as follows:

1. Identify Critical Information
2. Analyze the Threat
3. Analyze the Vulnerabilities
4. Assess the Risk
5. Apply the countermeasures

It really isn’t rocket science, but it is the sheer simplicity of the process that is alluring.  It has traditionally been applied in the military and has been used as a meta-discipline in security.  It assumes that other parties are watching, sort of like the aircraft watchers that park near the military base to see what is flying in and out, or the Domino’s near the Pentagon that reportedly sees a spike in deliveries to the Pentagon before a big military strike.  Observers are gathering critical information on your organization in new ways that you weren’t able to predict.  This is where OPSEC comes in.

Since there is no way to predict what data will be leaking from your organization in the future and it is equally impossible to enumerate all possible future risk scenarios, then it becomes necessary to perform this assessment regularly.  Instead of using an annual review process with huge overhead and little impact (I am looking at you, Sarbanes-Oxley compliance auditors), you can create a process to continue to identify risks in an ever-changing organization while lessening risk.  This is why you have a security team, right?  Lessening the risk to the organization is the main reason to have a security team.  Achieving PCI or HIPPA compliance is not.

Using OPSEC as a security process poses huge benefits when aligned with Agile software development principles.  The following weekly assessment cycle is promoted by SANS in their security training course.  See if you can see Agile in it.

The weekly OPSEC assessment cycle:

1. Identify Critical Information
2. Assess threats and threat sources including: employees, contractors, competitors, prospects…
3. Assess vulnerabilities of critical information to the threat
4. Conduct risk vs. benefit analysis
5. Implement appropriate countermeasures
6. Do it again next week.

A weekly OPSEC process is a different paradigm from the annual compliance ritual.  The key of the security is just that: lessen risk to the organization.   Iterating through the OPSEC assessment cycle weeklymeans that you are taking frequent and concrete steps to facilitate that end.

Why The Cloud Is More Secure Than Your Existing Systems

Saving the best of LASCON 2010 for last, my final session was the one I gave!  It was on cloud security, and is called “Why The Cloud Is More Secure Than Your Existing Systems.“  A daring title, I know.

You can read the slides (sadly, the animations don’t come through so some bits may not make sense…).  In general my premise is that people that worry about cloud security need to compare it to what they can actually do themselves.  Mocking a cloud provider’s data center for not being ISO 27001 compliant or having a two hour outage only makes sense if YOUR data center IS compliant and if your IT systems’ uptime is actually higher than that.  Too much of the discussion is about the FUD and not the reality.  Security guys have this picture in their mind of a super whizbang secure system and judge the cloud against that, even though the real security in the actual organization they work at is much less.  I illustrate this with ways in which our cloud systems are beating our IT systems in terms of availablity, DR, etc.

The cloud can give small to medium businesses – you know, the guys that form 99% of the business landscape – security features that heretofore were reserved for people with huge money and lots of staff.  Used to be, if you couldn’t pay $100k for Fortify, for instance, you just couldn’t do source code security scanning.  “Proper security” therefore has an about $1M entry fee, which of course means it’s only for billion dollar companies.  But now, given the cloud providers’ features, and new security as a service offerings, more vigorous security is within reach of more people.  And that’s great -building on the messages in previous sessions from Matt’s keynote and Homeland Security’s talk, we need pervasive security for ALL, not just for the biggest.

There’s more great stuff in there, so go check it out.

HTTPS Can Byte Me

This paper on the security problems of HTTPS was already presented at Black Hat 2010 by Robert Hansen, aka “RSnake”, of SecTheory and Josh Sokol of our own National Instruments.

This was a very technical talk so I’m not going to try to reproduce it all for you here.  Read the white paper and slides.  But basically there are a lot of things about how the Web works that makes HTTPS somewhat defeatable.

First, there are insecure redirects, DNS lookups, etc. before you ever get to a “secure” connection.  But even after that you can do a lot of hacking from traffic characterization – premapping sites, watching “encrypted” traffic and seeing patterns in size, get vs post, etc.  A lot of the discussion was around doing  things like making a user precache content to remove noisiness via a side channel (like a tab; browsers don’t segment tabs).  Anyway, there’s a lot of middle ground between “You can read all the traffic” and “The traffic is totally obscured to you,” and it’s that middle ground that it can be profitable to play in.