wickett

Book Review of The Phoenix Project

There is a great book out right now about devops and how it impacts your business. It is really good and you should definitely read it and buy 3 copies for your friends (or give those 3 copies to the people in your org stuck in 1997 doing waterfall and doing monthly or quarterly releases but I digress).

The Amazon.com teaser for the book reads:

Bill is an IT manager at Parts Unlimited. It’s Tuesday morning and on his drive into the office, Bill gets a call from the CEO.

The company’s new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill’s entire department will be outsourced.

With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.

In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they’ll never view IT the same way again.

What I really liked about this book is that this book exposed me to some new concepts and made some concepts that I was familiar with but didn’t understand more digestible and practical.  For instance, the book covers value stream mapping.  I had heard of it before, and I know it is something that all the Lean hipsters get excited about, but I couldn’t do it myself or walk someone through the process of how to do it.  When the team went through the value stream mapping exercise, it was super useful for me and I feel like I could do it or would at least know how to get started with that. 

That is one of many examples, and the book is full of great insights like this as it exposes concepts or ideas that you may be familiar with but wouldn’t be able to execute or perform yourself. The authors include quotes and ideas from Deming to Goldratt to Humble to Allspaw and do is in such an elegant way so that they paint a picture of what a good IT organization should look like. 

The team in the book working to transform the organization also included the security guy.  The security guy himself was a the complete personification of a phoenix (the mythical creature) maybe even more than any other character in the book as he completely rose from the ashes and transformed into someone who added value to the business instead of being a drain on resources. At the start of the book you got the feeling he was rooting for the business to fail the audit so the organization would have to pay penance for all their security sins. By the end of the book he was promoting rugged ideals and helping to inject security in the dev cycle with security testing being done at every code change. Being one of the core contributors to the gauntlt project, this was near and dear to my heart.  I strongly believe that you need to security testing on every code commit and that security testing shouldn’t wait until the annual PCI audit but should be codified into the dev environment.  (These are the drivers behind gauntlt and you can find out about how we do it from this AppSec USA video.)

I am still processing how this book will shape my philosophy about work and my career but I got excited about the significance of this quote, “In ten years, I’m certain every COO worth their salt will have come from IT.” The future is bright and technology can be a significant business advantage.

We are at the dawn of a new era in IT and The Phoenix Project can be your guide.

DevOpsSec by Nick Galbreath at DevOps Days Austin

#DevOpsDays Notes from Nick Galbreath’s (@ngalbreath) talk on DevOpsSec at DevOps Days Austin.

• Kicks off with “Trust but Verify” which is a saying I use regularly.  
• Nick, also scopes the talk to AppSec for the audience.
• Ops and Security have commonalities, both have latent problems: Ops has failure that has yet to happen, Security has unexploited vulnerabilities. 
• Also, both Ops and Security have a “say no” reputation
• Also, MTTR is for security as well as ops.
• Blending the cultures of DevOps and Security, you have to think about how fast can you deploy and build your security stuff: firewall, VPN, DB, schema changes, apps, app patches…  Deploy cant be limited to just your app, it has to be everything in the environment.
• Nick also brought up deployinator and its impact at Etsy.  [personal note that I need to do a full out post on this]  The usage of deployinator and the culture that brings with it, leads Nick to the following:
• “Being able to deploy quickly is my #1 security feature”
• Nick got approval to hire some extra firemen (aka security guys) to sit around waiting for fires… His response was that he is more worried about the house burning down without knowing.  How do we catch the fires before they get huge?  Firemen are useless when the house is gone.
• Security will care about events that Ops won’t notice and Devs wont test.  SQL injection is a perfect example because a couple of SQL queries will dump your schema, db, … all of it.  Ops alerts wont fire and likely your dev team didnt test for it.
• This leads Nick to talk about Attack Driven Testing (Login errors, Server errors, core dumps, CSRF Failures, XSS, Password failures)
• We should use assert to positively verify and test our system/code. (Ports, processes, users, …)  [My Note: I think tying with BDD (cucumber) would be sweet for this and I am doing a talk on Rugged DevOps shortly about this.]
• Another rule at Etsy is to not give your customers a virus.  They use their continuous integration environment to run AV on the code using ClamAV.

How a BigCo Actually Got Some Innovation Done by @Cote at DevOps Days

Michael Cote (@cote) goes through the history of crowbar and how they got it done at Dell.

• There are two types of people in the world… those that understand DevOps and those who dont.  They had to attack the competing ideas against crowbar internally and externally and did so with metaphors (soup vs. sandwich).  He also mentioned speaking through your customers and use their quotes–let them explain what you are doing.
• Always be Coding, not educating
• Get customers and users ASAP
• Work the Iron Triangle
• Find the right content
• Hiding Out, things are easier when no one knows they should care.  Best way to do this is to only talk limited scope about what you are working on.
• Get by with just enough architecting and abstracting - Lean baby, lean. See Lean Startup book.
• Don’t open source a box of junk.  (My note: This is what I did with Gauntlet and yeah, this is probably right.  Release running code.)
• Market the right stuff

DevOps and Security talk at DevOps Days by James Turnbull

Great talk at DevOps Days Austin by James Turnbull.  Here are a couple notes that stood out to me.

• Teaching the auditors to read the puppet manifests gives them the power to figure out what is in the org.  Creating empowerment and common language between groups.
• Security Ops is not that different from regular Ops, they are just focused on one specialty.
• Some security people are some of the smartest people in the org and know how to code better javascript than your devs and they run ops better than your ops.  They have been hacking JS for a long time and they have been managing the checkpoint firewalls for years.
• Dev and Security needs to interface early, not at the end, which is often the case.
• James listed top three things he hated about being in security: not being effective, not being happy, and not being liked. 
• Bridge Ops and Security.  Put security into the Ops escalation process, invite them to post-mortems and hook them into your metrics and data.  They are good at parsing data and detecting anomalies. 
• I wish I could have counted the number of times James said, “Security people are good at _______."  He has a healthy, positive view of the security folks in the org.

Great talk by @kartar and really hits home.

Adversity: Good for Software, Good for the Soul

Yesterday, I spoke at Hackformers on the topic of Adversity.  The premise was that adversity is ultimately good for software as it makes it stronger and as a result: rugged. I took a big bite at the apple and decided to extend that premise to the soul as well.  I should step back for a second and say that @hackformers is a Christian organization of Information Security professionals.  We get together monthly to chat security and discuss how it affects our personal and spiritual lives.  So for the group, merging the two areas of professional lives and personal lives is a natural fit.

Hackformers has a 3-fold goal for each meeting: Teach Security, Teach Christ, Teach Security in Christ.  It could also be said as: Information Security, Biblical insight, Personal application.

For the Teach Security portion of my talk, I have broken those slides out and uploaded them to slideshare in a talk titled: Adversity: Good for Software. 

Adversity: Good for software

The main premise I make in the slides is what I refer to as Ruggedization Theory, stated as: Building solutions to handle adversity actors will cause unintended, positive benefits that will provide value that would have been unrealized otherwise.  I go on to define Adversity Actors as: Those who regardless of intent or scope cause real or perceived negative actions and events that prohibit normal function and operation. 

I think the case for this is strong and apparent at the outset.  We have numerous real-world analogies and proverbs. If it doesn’t kill you it will make you stronger. No Pain, No Gain.  It makes sense that we build our code to withstand certain adversity actors, we will see positive benefit in other areas. 

At this point, I moved into a discussion on what this looks like from a Biblical perspective.  This fits into the “Teach Christ” vision of @hackformers.  I shared how pain is the most common objection to the faith–and we discussed the different variations on how scholars have addressed this particular objection.  For brevity, I am skipping this here, but feel free to ask me or to the @hackformers group at large.  The two verses I shared on the subject of adversity and its causal nature of benefiting the soul are James 1:2-4 and Romans 5:3-5.

Count it all joy, my brothers, when you meet trials of various kinds, for you know that the testing of your faith produces steadfastness.  And let steadfastness have its full effect, that you may be perfect and complete, lacking in nothing. - James 1:2-4 (ESV)

Not only that, but we rejoice in our sufferings, knowing that suffering produces endurance, and endurance produces character, and character produces hope, and hope does not put us to shame, because God’s love has been poured into our hearts through the Holy Spirit who has been given to us. - Romans 5:3-5 (ESV)

For the last section of the @hackformers,Teach Security in Christ, I talked about my journey in life through hard times.  I mentioned medical issues and other trying situations I have had, but the focal point of this section was the hardest time of my life: On March 1, 2007 I lost my brother to suicide.  The grief from that event was harder and bigger than I could bear.  This loss was way past the theory of adversity.  How could good become of this?  It wasn’t until I realized three things after walking several years through my journey.

1. My future hope is not here, it is in heaven.  Things here on earth will never be “right” and it is only until the future restoration of heaven.
2. The world is a broken and dying place.  This earth, even with the joy we sometimes experience, is fleeting.  Again, I look to future restoration.
3. Hope in Christ is the only hope.

Therefore we ourselves boast about you in the churches of God for your steadfastness and faith in all your persecutions and in the afflictions that you are enduring. This is evidence of the righteous judgment of God, that you may be considered worthy of the kingdom of God, for which you are also suffering—since indeed God considers it just to repay with affliction those who afflict you, and to grant relief to you who are afflicted as well as to us, when the Lord Jesus is revealed from heaven with his mighty angels… - 2 Thessalonians 1:5-7

The verses show that we look to the day when the Jesus is revealed from heaven.  Until then, we keep enduring and building character and above all keep the hope.

Top 5 SXSW Interactive Sessions I am most looking forward to

Every year I am pumped to go to SXSW Interactive as it is in my backyard and gets bigger and better every year.  This year, here are the talks I am most looking forward to.

1. The Lean Startup: The Science of Entrepreneurship - I have been following Eric (@ericries) for a while and hoping by attending this session I will get some ideas to take back to work.  Our team works like a start up inside a large organization and want to find some tips for navigating that structure.
2. Netflix and Twitter: What’s Under the Hood - This could be really cool and as our team is working on large scale cloud systems that scale on usage, this is a don’t miss session for me.
3. When IT Says No: How to Create Fast Feature Flow - If you haven’t learned already that I am a huge Gene Kim (@realgenekim) fan, then you must not know me well. A few years back at National Instruments, we did an internal book group on his book, Visible Ops. I was hooked. Since then, I have had the chance to hang out with Gene and get to know him personally. Trust me, you don’t want to miss this.
4. Freakin’ Fast Cassandra: How Do They Do It? - It has the words fast and Cassandra. What else do you need?
5. Securing Your Data in a Target-Rich Environment - Hak5 at SXSW Interactive!

Books I am reading right now

• The Tangled Web: A Guide to Securing Modern Web Applications
• Metaprogramming Ruby: Program Like the Ruby Pros
• The Cucumber Book: Behaviour-Driven Development for Testers and Developers
• Release It!: Design and Deploy Production-Ready Software
• The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws
• Hacking: The Art of Exploitation, 2nd Edition

The last two I am reading as part of book groups with Austin OWASP and with some security folks at National Instruments.

Pen Testing in the Cloud

Matt Tesauro (@matt_tesauro) discussed how testing in the cloud can be done and also did brief overview of OWASP WTE (Web Testing Environment) and its history.  It is astounding to hear that there have been over 300,000 downloads of the project and how it evolved.  The project started out–or at least Matt’s involvement started during–the OWASP Summer of Code in 2008.  After burning lots of CDs and several releases the project has moved to a Debian repo as it applies to more people and extends the environment to other use cases other than a CD–which we all know is so 1999.
 
This really grows once you want to expand to the cloud and allow devs and pen testers to build their own custom pen testing environments.  At the Austin OWASP meeting today, Tesauro went over the 12 steps needed to implement WTE in the cloud.  These 12 steps will get a fully functional WTE in the cloud and should take about 30 minutes.

Step 1: Get a cloud account

Step 2: Get an Ubuntu instance (xubuntu cuz its faster with xfce)

Step 3: Choose 2GB RAM for the box (name and tag it)

Step 4: Start your server

Step 5: Prep and update the box (ssh add ubuntu partners and WTE repo and run apt-get update)

Step 6: Install Desktop and WTE

apt-get –assume-yes –force-yes install xubuntu-desktop owasp-wte-cloud

Step 7: Add a NX Server (remote desktop for linux) - Uses no machine NX currently but will move to X2go later (probably).

Step 8: Setup your NX Client (win, linux, mac)

Step 9: Connect to WTE (uses SSH) - WTE in the cloud

Step 10: Test Connection

Step 11: Test tools (use intercepting proxy to rewrite page)

Step 12: Testing! and be sure to check your bill and pay it if you dare (pennies to use the cloud)


Couple of interesting notes for the project going forward:
1. Future project goals include using Apache libcloud for build automation.  
2. Also looking at swapping in X2go for the NX portion of this.  
3. I would also add a Vagrant build which is an extension of virtual box

See the full slides here > https://www.owasp.org/index.php/File:WTE-Cloud-Austin-2012-02.pdf