Parkour styled IT management

Archive for July, 2012

Parkour styled IT management

Posted by Wolf Goerlich

What can IT management learn from Parkour?

What? You have not heard of Parkour? It is a free running style sport that you can see in action on YouTube (youtu.be/WEeqHj3Nj2c). Also, check out the Parkour episode on Fight Science (youtu.be/RBNaiNnNRfU). A short summary is Parkour devotees create an awareness and nimbleness that allows quick fluid movements over uneven urban terrain.
Parkour has three takeaways that can be applied to leading an IT team:

  • There are no obstacles, only objects used to achieve an objective
  • Decrease shocks and distribute forces
  • Conserve energy and release it at the right time

There are no obstacles, only objects used to achieve an objective. A friend of mine who practices Parkour talks about raising an understanding about environment, and transitioning from seeing only obstacles to seeing only opportunities. I like that approach. The transition begins by pausing after anything happens and asking, how can this further our objective, build our brand, improve our services?

Decrease shocks and distribute forces. It is fair to say that not everything that happens to an IT team or on an IT infrastructure is positive. So what do you do then? In the Fight Science clip, Ryan Doyle jumps fourteen feet and then lands in such a way that he dissipates the force. The resulting impact on Doyle’s body is “similar to what a normal person feels doing jumping jacks.” IT teams can and should build systems and processes that are likewise capable of dissipating political and technical impacts.

Conserve energy and release it at the right time. Parkour experts can leap across several lanes of traffic. IT leaders can fund, execute, and secure large scale IT projects. The commonality? Both build energy, save it, and release it at just the right moment. Of course, in IT, that energy is measured by political capital, brag bags, team’s skill sets, potential cost saving ideas, and so on. The trick is knowing when and how to use this energy.

Sure, we may not look as impressive when carrying out an IT project as Ryan Doyle or Daniel Ilabaca. Still, I see a lot of Parkour in the IT leaders that I know. It is the CISO who rolls the right during an outage, thus dissipating the forces on the organization and the security team. It is the guy who leverages an outage to build a business continuity program. It is the manager who cuts the budget at just the right time to obtain funding for a new business critical initiative. I see it all the time. Applying these three simple lessons improves IT.

Not-so-secure implementations of SecureString

Posted by Wolf Goerlich

Microsoft .Net has an object for safely and securely handling passwords: System.Security.SecureString. “The value of a SecureString object is automatically encrypted, can be modified until your application marks it as read-only, and can be deleted from computer memory by either your application or the .NET Framework garbage collector”, according to the MSDN documentation. As with any security control, however, there are a few ways around it. Consider the following PowerShell and C# code samples.

 

# Some not-so-secure SecureString from a vendor whitepaper
password = Read-Host -AsSecureString -Prompt “Please provide password”

// Some not-so-secure SecureString code I wrote by mistake
private void button1_Click(object sender, RoutedEventArgs e)
{
  secretString = new SecureString();
foreach (char c in textBox1.Text.ToCharArray()) { secretString.AppendChar(c); }
  textBox1.Text = “”;
}

Try the samples above. Use something like Mandiant’s Memoryze or AcessData FTK Imager to get a copy of your current Windows memory. Search the memory for your password and, sure enough, you will find it in clear text. Sometimes, as with the C# code, you will find your password several times over.

What happened? In both cases, the value was passed to the SecureString in clear text. The SecureString is encrypted, however, the original input is not. That input value may stay in memory for a long time (depending what the underlying Windows OS is doing.)

Below are some examples of populating a SecureString in such a way that the password is not exposed in clear text. A the saying goes, trust but verify. In this case, trust the method but check using Memoryze or Imager to be certain.

 

# A secure SecureString implementation
$password = New-Object System.Security.SecureString
do {
  $key = $host.UI.RawUI.ReadKey(“NoEcho,IncludeKeyDown”)
  if ($key.Character -eq 13) { break }
  $password.AppendChar($key.Character)
} while (1 -eq 1)

// A more SecureString code example
private void button1_Click(object sender, RoutedEventArgs e)
{
  secretString = passwordBox.SecurePassword;
  passwordBox1.Clear();
}

Boulder rolling in Dark Reading

Posted by Wolf Goerlich

My BSides Cleveland talk got some attention, and was part of a Dark Reading article on risk management. Check out 4 Reasons Why IT Security Needs Risk Management, also available as a PDF on my Press page.

“Traditional IT security has what I think of as a Sisyphus complex,” says J. Wolfgang Goerlich, information systems and security manager for a Midwest financial services firm. “Every day, we roll the boulders up hill. We leave with as many systems, or boulders, secure as possible at the top of the hill. Overnight, new attacks are formed and new vulnerabilities are released. The next morning, some systems are insecure again, and we start again rolling boulders back up hill.”

According to Goerlich and many of his peers, if security organizations are to evolve past that daily toil and affect meaningful change on their respective businesses, they need to embed risk management principles in their decision-making framework. “Moreover, rolling the boulder isn’t the goal of security, but rather the goal is securing the ability of the organization to accomplish its mission,” he says. “Risk management is an important technique that focuses security efforts on the organization’s mission and prioritizes efforts on critical systems.”

But what is important to the organization? What value does any given piece of technology deliver to the organization’s mission? To answer these questions, we have to step back first.

The first step in building an effective security program is aligning with executive management and tying security tasks back to business objectives. Once that is done, we can move on to building a ITGRC function (IT governance, risk, and compliance). But executive sponsorship is key, otherwise, it will be extremely difficult to get feedback and support from the business units. The importance of this support cannot be overstated. Pierluigi Stella, CTO, Network Box USA, says: “Proper risk management is done when IT is only the project manager but every single business unit contributes its own knowledge to the process; and this needs to start from the top, from the C levels.”

It is all part of building a mature information security program. For my full thoughts on building such a program, you can watch my BSides Cleveland Naked Boulder Rolling talk.

Let me tell you why you are right

Posted by Wolf Goerlich

I had the conversation a few times on Friday. You know the one. The one techies always have when they are with techies. The one where you are wrong and they are ready to tell you why.

Yep. I had a few conversations. What is better, Hyper-V or VMware? Azure or Amazon? DerbyCon or GrrCon? Following Rafal Los or not? *

I answered in my typical measured fashion. Take GrrCon, for example. I like promoting local talent. I like Chris and Jaime Payne. I am speaking there, as are a number of my friends. GrrCon was good to me last year and I am looking forward to returning this year. That is my bias.

“Wow,” the guy who asked remarked, “I’ve never heard someone explicitly tell me they were biased and then only say why they are making a decision. Usually people just tell me what they think I should do.”

That is telling, isn’t it?

My approach to the conversation is simple. I will tell you why I made my decision. If you would like, I can enumerate my reasons behind it. And when my reasons change, my decision will change. I see no reason to get my ego wrapped up in a decision.

So let me tell you why you are right. You are right because you weighed the evidence. You are right because you took into account your strengths and weaknesses, and the strengths and weaknesses of your team. You are right because you compared features and benefits. You are right because you made a choice based on the culture of your organization and industry. You are right because you made a decision that was right for you.

You are right. Now you made a decision that was different from mine. Why not tell me a bit more about what you decided?

Wolfgang

 

 

* Footnote: None of these were as vicious as the Linux versus Windows conversations of old. But it struck me as an odd progression. We used to argue over operating systems and chips. Today we argue over virtualization and cloud. That is progress, I suppose. But why are we arguing over places and people? It seems like a strange turn of events.

BSidesCleveland 2012

Posted by Wolf Goerlich

I went to BSides Cleveland last Friday. We put the word out to the #misec mailing list, and took a couple of carloads of Michigan IT/InfoSec pros down to Ohio. The conference was well run, the swag bags were well stocked, and everyone I spoke with enjoyed themselves. Below are some of the highlights.

Dave Kennedy (Rel1k) kicked off the conference. Dave has recently made the transition from Diebold’s CSO to CEO at TrustedSec. Dave demoed some advanced pentesting techniques using the Social-Engineer Toolkit (SET). Of note, did you see the news on the new scary attack that knows your OS? Yeah. That was Dave’s code being re-used. Whoops.

Next up was Bill Mathews (@billford) on cloud security. I have a reasonably sound understanding of cloud computing and cloud security. I went to Bill’s talk to get ideas on how to talk with non-infosec people about cloud concepts. Bill did not disappoint. He had a good talk, kept my interest, and provided a one page cheat sheet at the end. (These sheets are on their way to my team already.) You can see Bill’s slides and cheat sheet at Hurricane Labs.

I attended Jeff Kirsch’s talk next (@ghostnomad). As a haiku fan and long-time reader of Jeff’s blog, I really wanted to meet Jeff. He is also a hard guy to meet because I rarely see him at other conferences. Finally I had my chance! Moreover, I identified end-user training as a weakness in my security program and I am on the lookout for ways to improve. The “<? $People ?> Process Technology” talk was informative and helped steer me in the right direction.

Jeff joined us for lunch at the Winking Lizard Tavern. We got to talk secbiz, rail against auditors who don’t get it, rail against IT managers who don’t get it, and basically geek out on the business side of infosec. I rarely get to scratch the business itch and so this was a real treat.

After lunch, I gave an updated version of my Naked Boulder Rolling talk. How did this compare to the one I gave in June? Detroit was more fun and Cleveland was more satisfying. That is to say, I enjoyed the audience participation and humor while presenting in Detroit. The only problem was that it meant a good quarter of my talk was cut due to time. In Cleveland, I was able to present the material in full. I felt the overall message of the talk was conveyed more clearly. I fielded some good questions afterwards that have me thinking of making a new ITGRC deck.

With Matt Johnson’s incident talk fresh in my mind, I joined Mick Douglas’s talk on Automating Incident Response. Mick’s metaphor was building a sprinkler system to respond to the burning building that is the security breach. Add to that the research that shows how exponentially expensive a breach gets the longer it goes undetected, and Mick has a powerful argument. He wrapped up by demonstrating Python scripts that respond to incidents using network segmentation and throttling. Mick gave me a few ideas that I am going to try on my own network gear this coming week.

I sat in on a talk by James Siegel (@WolfFlight) next. James has been thinking about moving the security conversation beyond the echo chamber for some time. At BSides Detroit, he brought a hallway con discussion around the topic that led up to a podcast. It was decent for a first time presenter. James employed some humorous visuals featuring Looney Toons to provide a clear call to action: let’s educate non-technical folks.

I walked into the next session chanting “.net! .net! .net!” Some might argue that was because of all the free Bawls drinks. But, no, I was excited to see Bill Sempf‘s perspectives on application security. Bill walked us thru ASP.NET controls for the OWASP top ten, and touched upon using Back|Track for validation. The key insight from this talk was using Back|Track scripts to validate code as part of the build process. This dove-tails nicely with my philosophy of baking infosec into the work, and I am looking to explore the concept further in the next few months.

The conference wrapped up with a two hour after party, and then a three hour drive back home. I had a number of great conversations over those five hours, and spent yesterday collecting notes and pulling down content. BSides always leave me fired up to do more, learn more, and see more. BSides Cleveland once again proved why community conferences are so inspiring. All I can say is, when do we get to do it again?

Kudos Dave DeSimone and the Cleveland organizers, and thank you to sponsors: Diebold, Accuvant, FireEye, f5, Bit9, DerbyCon, Hurricane Labs, Neoisf, SecureState, Rapid7, and McAfee.

Update: The videos for all BSides Cleveland talks are now online: http://www.irongeek.com/i.php?page=videos/bsidescleveland2012/mainlist

Focusing the diffusion of innovation

Posted by Wolf Goerlich

Many books talk about the diffusion of innovation and the division of the population into a bell curve of innovators, early adopters, early majority, late majority, and laggards. A person in the innovators or early adopters category, some books suggest, will have the latest television, be the first to get the newest mobile telephones, and be up to date on the latest and greatest products.

I have a Panasonic tube television manufactured in the nineties. My phone is a BlackBerry Storm. I am sorry to say that my iPad is gen 1 and still has iOS 4. And yet, many people remark on how innovative my team is with technology. So what gives?

In a word: focus.

IT management needs to be sharply focused on their value proposition. Mine is delivering technology at the nexus of business value, team passion, and team skill. The value proposition effectively splits a team into eight states. On the low side, a particular area can be anywhere between low value, low passion, low skills and high value, high passion, and high skills.

Focus innovative thinking on only areas that drive high value. This takes discipline. I would like more than anything to tinker with a new phone, try out a new iOS, maybe write an app or two. However, we deal with finite resources and limited time. By conserving energy for areas that really drive value, we can be more innovative in ways that are more effective.

Below are the value proposition and the corresponding diffusion of innovation.

  1.  Low value, low passion, low skills. Laggard: put in the least amount of resources.
  2. Low value, low passion, high skills. Late majority: how can we meet this need by practicing our skills?
  3. Low value, high passion, low skills. Late majority: how can we scratch the itch and satisfy the need?
  4. Low value, high passion, high skills. Early majority: we have the interest and know-how. Use it.
  5. High value, low passion, low skills. Early majority: partner but move quickly.
  6. High value, low passion, high skills. Early adopter: create excitement thru being innovative.
  7. High value, high passion, low skills. Early majority: be a fast follower to build skills.
  8. High value, high passion, high skills. Innovators: give the process your full attention.

Steven Fox’s Social Illusion

Posted by Wolf Goerlich

Steven Fox (@SecureLexicon) has been giving a series of talks on creating social illusions. Last Friday, I joined Steven at EMU where he was presenting as part of EMU’s IA summer workshop series. The topic was spearphishing. Steven demonstrated using Maltego to create an email, while Evan Malamis showed how the Social Engineer Toolkit could weaponize and distribute the email.

Let’s suppose Steven was deliberately targeting someone who attended BSidesDetroit. What should the email look like, and who should it be from?

The first thing Steven did was create a social network nodal graph from BSidesDetroit. By navigating the graph, it became obvious there was a tight network bond between Matt Johnson, Derek Thomas, and myself. There was an “ah ha!” moment as Steven explained how a message to a target could be sent from any one of us three.

Now what topic should the email use? Steven pivoted Maltego and pointed out an interesting relationship between BSidesDetroit  and BSidesChicago. So he graphed BSidesChicago, and looked for intersections. From there, he probed to see how those intersections touched upon Matt, Derek, and me.

Out popped a tweet from Mr. Minion on the Chicago ISACA/ISSA boat cruise. Steven pulled the tweet and resulting social interactions into another graph. There, it became obvious that #misec was involved. Steven was able to pull out several key pieces of information, including URLs and the like.

The final step of the process was to write the email. Essentially, Steven combined Maltego results with some Google fu to determine how #misec would pitch an event. The look, the feel, and the tone of the message were carefully crafted. Steven even perfectly emulated my writing style. (Take a look for yourself here.)

How successful was this forgery? Consider the following three pieces of evidence.

First, one person immediately commented: “Does that count? We all know the #misec guys are doing this boat thing.” Except we are not. The interesting thing is that #misec is not actively planning a river cruise. Yet the email was so well done that the audience immediately assumed we were.

Once that was explained, another person went: “It is funny you mention the cruise. I would have clicked on it because I remember Elizabeth Martin talking about Detroit doing a boat cruise.” This turned out to be a case of person’s memory adjusting to fit the facts they saw in front of them. Checking with Elizabeth, she did not talk about the cruise during BSidesDetroit at all.

Actually, the Twitter buzz preceeded me checking with Elizabeth Martin. All the buzz led Elizabeth to the logical conclusion that there was a cruise, and she spent an hour researching boats for our event. She later tweeted out: “The best part is I thought I was supposed to plan a cruise so I started working on it!”

Think about that for a moment. Steven Fox effectively invented an event. He crafted a message so accurate that it caused people to remember it, had people believing it was actually happening, and effectively created its own reality. Talk about creating social illusions!