wickett

Book Review of The Phoenix Project

Sat, 09 Mar 2013 08:19:32 -0600

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.

My presentation at AppSec USA 2012

Wed, 28 Nov 2012 14:13:04 -0600

My presentation at AppSec USA 2012

I delivered this deck at the OWASP Austin Lightning Talks during...

Mon, 10 Sep 2012 13:17:00 -0500

I delivered this deck at the OWASP Austin Lightning Talks during the July 2012 meeting.

DevOpsSec by Nick Galbreath at DevOps Days Austin

Tue, 03 Apr 2012 10:26:38 -0500

#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

Mon, 02 Apr 2012 11:21:24 -0500

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

Mon, 02 Apr 2012 10:50:46 -0500

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

Sat, 17 Mar 2012 15:18:00 -0500

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.

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.
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.
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

Mon, 05 Mar 2012 17:32:17 -0600

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.

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.
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.
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.
Freakin’ Fast Cassandra: How Do They Do It? - It has the words fast and Cassandra. What else do you need?
Securing Your Data in a Target-Rich Environment - Hak5 at SXSW Interactive!

Books I am reading right now

Wed, 29 Feb 2012 23:24:26 -0600

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.

"Yes, I consider the DevOps movement to be an affront to my craft. How could I not? How could I look..."

Tue, 28 Feb 2012 17:01:40 -0600

“

Yes, I consider the DevOps movement to be an affront to my craft. How could I not? How could I look at their smug build scripts and their repeatable processes and not see it for what it is: a crass commercialization of server creation!

I ask you this: what good is a process without a soul? What good is efficiency without beauty? What good is building servers without the human touch?

”

- “DevOps is Ruining My Craft”

Pen Testing in the Cloud

Tue, 28 Feb 2012 13:08:00 -0600

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

"Rugged software is software that is going to run as intended, regardless of the conditions it..."

Tue, 21 Feb 2012 10:00:05 -0600

“Rugged software is software that is going to run as intended, regardless of the conditions it encounters when it is deployed.”

- Interview with @danielcornell on Rugged Software at the agile admin blog

Coding Secure Infrastructure in the Cloud using the PIE...

Mon, 20 Feb 2012 10:42:33 -0600

Coding Secure Infrastructure in the Cloud using the PIE framework presented at LASCON 2012.

Rugged by design DevOps by culture

Sun, 19 Feb 2012 15:17:26 -0600

Rugged by design DevOps by culture:

These are the R’s of a Rugged DevOps implementation. Wrote this short blog post after going through some old slides from last fall.

Monitoring Sucks but Alerting is Beautiful

Sun, 19 Feb 2012 14:51:00 -0600

Monitoring Sucks but Alerting is Beautiful:

The devops toolchain is not complete without an elegant way of handling alerts. I write for the agile admin blog and posted this today on my team’s use of PagerDuty and how to implement it into your devops team.

"The average Software Security Group size is 1.99% of development group size"

Sat, 18 Feb 2012 16:12:40 -0600

“The average Software Security Group size is 1.99% of development group size”

- What’s in Your Program? Application Security Maturity in 2011 presented by Joel Scambray, January 31, 2012 at Austin OWASP Chapter. Taken from BSIMM data.

certifiable: a comment on infosec certs and training

Fri, 17 Feb 2012 10:36:33 -0600

There are a lot of people out there who think that security certifications are a waste of time and are just for people who value paper over experience and for certification issuing organizations to cash in. I differ in opinion, and here is why:

Education. Not everyone is fortunate (or unfortunate depending on your perspective) enough to land a pure infosec job. The certs and the training and studying accompanying them allow augmentation and career growth that would otherwise be hard to squeeze in our day-to-day. Sure we could learn and experiment on our own, but in real life you can’t live at a hacker space and pay the bills. Having a goal to reach encourages you to apply yourself in the material and subsequently learn more than if you were left to your own devices.
Differentiation. Lets say I am a hiring manager for an auditor position and I want to hire a forensics person. I am going to look at their experience and any certifications they hold to help filter candidates. Having a GCFA (GIAC Certified Forensics Analyst) certainly doesn’t hurt and will at least get you in for an interview.
Accountability. While (ISC)2 has a lot of flaws, it does make an attempt at accountability where the candidate has to prove relevant work experience, get signoff from another CISSP and submit annual CPE hours. It isn’t a perfect system, but it is an attempt to keep people honest. Other organizations could learn from this and honestly (ISC)2 could learn how to do this better.
Specificity. In my opinion some of the best certifications and training out there is being put on by the SANS organization. It isn’t cheap, but it is relevant and specific. Certification is available for specific disciplines (Network Pen Testing, Firewall Analyst, Incident Handling) and that level of specificity helps hone in on skills and knowledge needed—not an “inch deep and a mile wide” as other organizations say.
Integrity in exams. One more note about SANS is that they have proctored open-book exams and their tests are built to test understanding and experience and not just rote memorization. They are difficult to pass with out in-depth understanding of the subject. They also offer “Gold” certs where the candidate submits a peer-reviewed paper—which gets back into #3 (accountability).

It is hard to justify expensive training and pursue certs that don’t represent reality. I know that a lot of certified individuals are better labeled as certifiable. In fact the worst presentation I have ever seen on Cloud Security was given by a CISSP which saddened me. But all-in-all I think there is some value to certs. And for full disclosure I should note that I have several. I have seen direct, positive impact on my career and have been exposed to education that I wouldn’t have had otherwise.

the history of security engineering

Wed, 08 Feb 2012 22:32:52 -0600

Just getting into ‘The Tangled Web’ by Zalewski and highly recommend the book after getting only a few pages in. He cleverly weaves together the history of security and how security engineering appears to be a firm discipline on the outside but has limited substance on the inside. As such the industry started to form a culture where insecure software is ‘ok’ as long as the risk had been accepted, leading us down the path—probably the wrong path—of risk management.

This jives with what I have been feeling as I have always hated risk management and treating security like an actuary science rather than practical engineering. I am not an insurance sales person or policy writer, nor am I an auditor. Instead, I am driven to be a builder and someone who builds ruggedized systems that can withstand adversity. That is where the passion of security can really be utilized to add true business value and show relevancy of its discipline.

More to come, but really excited about this book so far.

Photo

Fri, 11 May 2007 10:57:00 -0500