How long does it take to go from excitement to panic? Put differently, how long is the vulnerability lifecycle?

We know the hardware side of the story. Moore's law predicts transistors density double every 18 months. On the street, factoring in leasing, this means computing power jumps up every 36 months.

Now let's cover the software side of the story. It takes a couple of years for software ideas to be developed and to reach critical mass. We see a 24-month development cycle. Add another 6-12 months for the software to become prevalent and investigated by hackers, both ethical and not.

I made a prediction this past weekend. Some at BSides Chicago were calling this Wolf's Law. Not me. I checked the video replay. Nope. It is simply a hunch I have. Start the clock when developers get really excited about software, tools, or techniques. Stop the clock when a hacker presents an attack at a well-known conference.

Wolf's Hunch says it takes 36 month's to go from excitement to panic.

As a security industry, the trick is to get ahead of the process. How could we engage the developers at months 1-12? One way might be to attend dev conferences. Here is how I put it at BSides Chicago:

"You know what is scary? Right now, as we are all in here talking, there is a software developer conference going on. Right now. There are a whole bunch of software developer guys talking about the next biggest thing. 36 months from now, what the developers are really excited about, we will be panicking about."

I checked the news this morning. During this past weekend, NY Disrupt was in full swing. At approximately the time I was speaking, developers were hard at it in the Hackathon. Lots of people are excited about the results, such as Jarvis:

"Jarvis works, using APIs provided by Twilio, Weather Underground and Ninja Blocks to help you control your home and check the current conditions, headlines and what's making news, and more, all just by dialing a number from any telephone and issuing voice commands, It's like a Siri, but housed on Windows Azure and able to plug into a lot more functionality.”

Uh huh. A Jarvis. Voice control. Public APIs. What could possibly go wrong?

Will my hunch play out? Check back here in May 2016. My money is on a story about a rising infosec star who is demonstrating how home APIs can be misused.

I am presenting a breakout session at this year's Great Lakes InfraGard Conference. Hope to see you there.

Securing Financial Services Data Across The Cloud: A Case Study

We came from stock tickers, paper orders, armored vehicles, and guarded vaults. We moved to data bursts, virtual private networks, and protocols like Financial Information eXchange (FIX). While our objective remains the same, protect the organization and protect the financial transactions, our methods and technologies have radically shifted. Looking back is not going to protect us.

This session presents a case study on a financial services firm that modernized its secure data exchange. The story begins with the environment that was developed in the previous decade. We will then look at high-level threat modelling and architectural decisions. A security-focused architecture works at several layers and this talk will explore them in depth; including Internet connections, firewalls, perimeters, hardened operating systems, encryption, data integration, and data warehousing. The case study concludes with how the firm transformed the infrastructure, layer by layer, protocol by protocol, until we were left with a modern, efficient, and security-focused architecture. After all, nostalgia has no place in financial services data security.

Some good tips on this article:

How to get the most out of a small IT staff
http://www.mrc-productivity.com/blog/2013/02/how-to-get-the-most-out-of-a-small-it-staff/

• Use web apps
• Give them the right tools
• Choose vendors wisely
• Empower end users
• Move what you can to the cloud
• Know your team

I am on the latest BSides Chicago podcast episode: The Taz, the Wolf, and the exclusives. Security Moey interviewed me about a new talk I am developing for Chicago, titled Surviving the Robot Apocalypse.

The inspiration comes from Twitter. Tazdrumm3r once said, "@jwgoerlich <~~ My theory, he’s a Terminator from the future programmed 4 good 2 rally & lead the fight against SkyNet, MI branch." A few weeks back, we were discussing the robotics articles I wrote for Servo magazine and some 'bots I built with my son. To which, Infosec_Rogue said, "@jwgoerlich not only welcomes our robot overlords, he helped create them."

I can roll with that. Let's do it.

The goal of this session is to cover software security and software vulnerabilities in an enjoyable way. Think Naked Boulder Rolling and Risk Management. Unless, of course, you didn't enjoy Naked Boulder Rolling. In that case, imagine some other talk I gave that you enjoyed. Or some other talk someone else gave that you enjoyed. Yeah. Pick one. Got it? Surviving is like your favorite talk, only for software security principles and their applicability to InfoSec.

I hope to see you in Chicago.

Surviving the Robot Apocalpyse

Abstract. The robots are coming to kill us all. That, or the zombies. One way or the other, humanity stands on the brink. While many talks have focused on surviving the zombie apocalypse, few have given us insights into how to handle the killer robots. This talk seeks to fill that void. By exploring software security flaws and vulnerabilities, we will learn ways to bypass access controls, extract valuable information, and cheat death. Should the unthinkable happen and the apocalypse not come, the information learned in this session can also be applied to protecting less-than-lethal software. At the end of the day, survival is all about the software.

I have been doing more with PowerShell recently. One thing that troubled me was that my color, font, and size settings were not sticky. I would get PowerShell configured just right. But when I would launch PowerShell from the cmdline or use it to debug in Visual Studio, my personal settings would be lost.

The cause is that the settings in a console session are applied to the shortcut link. The settings are not applied universally to the user profile. Suppose you start a console and click the console icon to set the font, layout, and color. These settings are saved in the shortcut that was used to launch that particular console.

To persist across sessions, you need to update the default values in your user profile. This is stored in the registry under HKEY_CURRENT_USER\Console.

The command prompt is under: [HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe]

The PowerShell prompt is under: [HKEY_CURRENT_USER\Console\%SystemRoot%_system32_WindowsPowerShell_v1.0_powershell.exe]

Here are the values:

ColorTable00 == dword storing the background color in blue, green, red.
ColorTable07 == dword storing the foreground color in blue, green, red.
FaceName == string storing the name of the font, such as "Lucida Console".
FontFamily == dword set to 0x36 for fixed width fonts.
FontSize == dword set to 00, then the font size in hex, then 0000. For example, 10-point (0xA) font is 000A0000.
FontWeight == a dword defaulting to 0x190.
WindowSize == a dword in coord format: 2-byte height and 2-byte width. For example, 0028 0078 is 40 characters tall by 120 characters wide.
ScreenBufferSize == dword in coord format. Note the WindowSize cannot exceed the ScreenBufferSize.

I prefer a retro green screen console with large fonts and a large buffer. Here are the values from my registry:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Console\%SystemRoot%_system32_WindowsPowerShell_v1.0_powershell.exe]
"ColorTable00"=dword:000f2000
"ColorTable07"=dword:0000f000
"FaceName"="Lucida Console"
"FontFamily"=dword:00000036
"FontSize"=dword:00100000
"FontWeight"=dword:00000190
"WindowSize"=dword:00280078
"ScreenBufferSize"=dword:012c0078

Chapter 2: In which Mark gives Wolfgang OSX envy.

Earlier this week, I published a speed test comparing Gnu grep and PowerShell Select-String. Mark Boltz (@mtezna) posted a follow-up titled The grep Project over on Mark's blog, The Tao of the Net. OSX appears to offer a substantial performance increase over Windows when executing both Gnu grep and BSD grep.

Check it out. Mark and I are comparing notes.

How fast is grep? Reasonably fast. Over the weekend, we were discussing on Twitter a post from Mike Haertel. Mike was the original developer of GNU grep. In the post titled "why GNU grep is fast", Mike described the algorithm grep uses. He also provided this excellent advice: "#1 trick: GNU grep is fast because it AVOIDS LOOKING AT EVERY INPUT BYTE. #2 trick: GNU grep is fast because it EXECUTES VERY FEW INSTRUCTIONS FOR EACH BYTE that it *does* look at." "The key to making programs fast is to make them do practically nothing."

This had me wondering about how PowerShell's Select-String stacks up. Richard Minerich (@rickasaurus) brought up a good point: compiled C code is generally faster than C# code. As PowerShell rests on .NET, we can make an assumption that grep should be faster than Select-String. Mark Boltz (@mtezna) suggested running several tests of both and taking an average to get a sense of how Select-String stacks up.

If Select-String was significantly slower, then a good weekend project might be to write a faster parser. I do have the occassional free weekend and I was very curious. Today, I performed such a test. Read on to find out what I learned.

Test Parameters

I generated sample files using a sample dictionary file. Each file contained sentences of random length (5-25 random words). One in ten sentences contained the word "key" at a random location within the sentence. There were eleven sample files: 1,000 sentences, 10,000 sentences, 20,000 sentences, and so on to 100,000 sentences. (You can download the resulting test files here: grep-select-string-test.zip).

Each search was performed seven times. System.Diagnostics.Stopwatch was used as the time source. The total milliseconds elapsed was used as the time measure. The minimum time and the maximum time were dropped. The time recorded was the average of the remaining five tests.

I used the latest GNU grep for Windows, version 4.2.1 released 2012-12/18. The command executed for grepping the file was: grep "key" "file1000.txt"

For PowerShell, I used version 3 (build 6.2.9200.16398).  The PowerShell equivilant of the grep command was: Select-String -Pattern "key" -Path .\file1000.txt

The host operating system is Windows 2008 Server R2 SP1 with the latest hotfixes.

Results

In the following graph, the number of lines in the sample files is plotted on the x-axis. The total time to search the sample file is plotted on the y-axis in milliseconds.

The bottom line? Select-String is significantly faster than GNU grep on Windows Server 2008 R2. PowerShell is closing the gap between Linux and Windows shell environments.

Matt Johnson and I will be presenting on incident management and PowerShell at next month's Motor City ISSA. This is part of the PoshSec initiative.

Incident Management with PowerShell

Have you seen the latest scare? The Java 0-day exploit that allows attackers to execute code on your computer? Now scares come and scares go. But let’s suppose for a moment your servers were infected using this exploit. How could your administrators detect the attack? How would you recover? Even better, what could have been done beforehand and how could you prevent this from happening again?

Incident Management, of course, is the security practice that seeks to answer these questions. In Windows server environments, PowerShell is the way Incident Management gets put into practice. This session will introduce InfoSec professionals and systems administrators to PowerShell’s security features. We will provide an overview of Incident Management and PowerShell. Then, using the Java 0-day exploit as a driver, we will walk through the lifecycle of an incident. The audience will leave with information on the policy and practice of managing security incidents in Windows with PowerShell.
 
Biography:

J Wolfgang Goerlich is the information systems and security manager for a Michigan-based financial institution. He is responsible for managing the software development and network operations team. Wolfgang's background is in architecting new systems, securing existing systems, and optimizing performance and recovery. With over a decade of experience, Mr. Goerlich has a solid understanding of both the IT infrastructure and the business it enables.

Matt Johnson is a Systems Analyst from the Metro Detroit area. As an avid technologist and tinkerer, he is always looking to understand and improve the world around him. Matt has a strong interest in automation and the use of PowerShell. Matt founded the SE Michigan PowerShell User Group and was a judge for the last two years for the Microsoft Scripting Games. He holds numerous certifications and writes a blog at http://www.mwjcomputing.com. You can follow him on twitter by following @mwjcomputing.

Motor City ISSA. February 21st, 2013. Livonia, MI.

Least Privilege Management (LPM) is in the news ...

The concept has been around for decades. J. Wolfgang Goerlich, information systems and information security manager for a Michigan-based financial services firm, said it was, "first explicitly called out as a design goal in the Multics operating system, in a paper by Jerome Saltzer in 1974."

But, it appears that so far, it has still not gone mainstream. Verizon's 2012 Data Breach Investigations Report found that, of the breaches it surveyed, 96% were not highly difficult for attackers and 97% could have been avoided through simple or intermediate controls.

"In an ideal world, the employee's job description, system privileges, and available applications all match," Goerlich said. "The person has the right tools and right permissions to complete a well-defined business process."

"The real world is messy. Employees often have flexible job descriptions. The applications require more privileges than the business process requires," he said. "[That means] trade-offs to ensure people can do their jobs, which invariably means elevating the privileges on the system to a point where the necessary applications function. But no further."

Read the full article at CSO: Privilege management could cut breaches -- if it were used