Side-step Shellshocks the “5+2” Way—3 Lessons for You
3 min read
Security professionals were largely blindsided by Shellshock. Was there a process by which it could have been more easily found? Yes, 3 lessons can help business and IT leaders help their security teams get ahead—and protect the public from the attack of the high tech toaster oven.
Shellshock is a popular name for a new security exploit in the UNIX Bash shell (first released in 1989). One meaning of “Bash” is “Bourne again shell” where “Bourne” refers to the shell created by Steven Bourne in 1977 to replace an earlier shell. A “shell” provides a way—originally a command line—for a person to access operating system functions.
Lesson #1: Be “old school,” use what you know to ask “how?” and “why?”
Tech-savvy business and even IT leaders can feel intimidated by new tech. Yet, old school often helps. Shellshock attacks a code gap that seems to be over a decade old. Further, many people forgot that a key feature of the Bourne shell was scripting—similar to scripts for automating simple tasks in word processing and spreadsheet documents.
Scripting should ring a bell as one of the first tools used by hackers. That is why black hat newbies are called “script kiddies.” Script kiddies wanting to do damage with other scripting languages will easily find this group of scripting tools, even in dusty IT books.
The black hat systematic search for knowledge must be answered by your systematic race to find that knowledge first. Controls are the wrong tool for the job.
Lesson #2: Shell games and war games
“Shall we play a game?” You might have been puzzled by this question from Black Widow to Captain America in Captain America: The Winter Soldier (2014). If you are a film buff, you would remember the question in War Games (1983) posed by the nuclear missile computer to a young gamer played by Matthew Broderick.
The world was saved because Broderick’s character grasped how the code worked. This reminds us to know “how it works,” confirm old code is good code, and war game our way to prevention with the systems-aware 5+2 Risk Management Cycle. For more film lessons see, Managing Risk in Reel Time.
Lesson #3: Evaluate your environment and capabilities
Step 1 in the 5+2 Risk Management Cycle is “Evaluating Environment and Enterprise Capabilities.” Business leaders often say “Know your business!” For IT pros, it is “know your code,” including the environment variable.
Shellshock amplifies its power from how Bash can be tricked through the environment variable and a bit of scripting—black hats knew the system better than white hats.
The error in so many risk management processes is they skip steps—failing to use the 5+2 Risk Management Cycle to be systematic. This was a key point in the recent workshop at the ISACA San Francisco Chapter.
The 5 continual steps of the 5+2 Risk Management Cycle are:
- Evaluate the environment and enterprise capabilities—“Know the business.”
- Seek scenarios—rigorously ask, “What if?”—the heart of managing risk
- Watch for warnings
- Prioritize
- Improve position in environment and/or capabilities
The “+2” are about reacting to warning signs and recovering.
The 5+2 Risk Management Cycle applies to business strategy and product management as well as cyber war. Thus, business leaders can use a familiar approach to guide their IT teams.
We’ll be discussing this at the New York Metro Joint Cybersecurity Conference (7 October) and ISACA Curacao Chapter Conference (15-17 October). Join us. Together, we can make a difference.
Brian Barnier, ValueBridge Advisors, has served ISACA in a range of roles. He is the author of The Operational Risk Handbook, at the ISACA Bookstore. [email protected]
[Source: ISACA]
English