Monkeys move with curiosity, agility and speed. When competing for a prize, they focus on their prize and use their knowledge to race to where the prize will be, not where it was. They quickly adjust their speed to match the speed of the situation. Creatures of the wild take advantage of their capabilities in their environment.
We can all stand to learn from these animals because a contributing factor to security failure root cause is frequently the organization’s inability to move at the speed of the wild.
After presenting at ISACA and IIA programs earlier this year, I heard a common statement from auditors: “it is all moving too fast.”
Auditors described how they attempted to apply audit methods (even good ones) and yet suffered security problems. “We just need more auditors,” said one in exasperation.
Will more auditors fix security? No. As those familiar with ISACA know, there is a big difference between the methods for daily use of a COBIT implementation and a periodic audit of a COBIT implementation.
Assurance is about whether policy, procedure, standards and such existed and were complied with at a past point in time. Audit “risk assessment” is about top priorities for audit, not about risk to specific business objectives in a dynamic world. Audit scope may be any agreed-upon bite-sized piece, not the organization’s entire dynamic world.
Security must happen every second of everyday. The scope is the entire living system with all its change, complexity and fatigue in people and equipment. Security must adjust to each change in actor, action, attack method, infrastructure configuration and timing.
Assurance methods may be used to audit whether appropriate security processes exist. Assurance methods should never be used to actually manage security—they are simply the wrong tool for that job.
Because assurance is about achieving business objectives, the audit function is central to assuring the right tool is used for the job.
The wrong tool for the job often increases risk and wastes time and money. Worse, it might provide a false sense of security and divert attention from higher priorities.
Looking to the future, the wrong tools will increasingly struggle as attackers learn more lessons in deception from the history of warfare, sports or the wild.
Methods must change. To meet the threat, methods must be able to move at the speed of the wild. Further, methods must succeed in the “dirty” wild—a system where users and devices frequently change.
Designed to move at the speed of the wild is the 5+2 Step Cycle for managing risk. Step 1 is “know the business,” including “dirty” environments. Step 2 is “what if?”—the heart of managing risk. By understanding the speed at which a scenario unfolds, a response can be designed in light of the entire system and how a system is likely to fail.
The 5+2 Step Cycle achieves this speed because it was designed to:
Be simple, to avoid adding complexity to system complexity and thus increasing risk
Save time and money—effectively creating resources thus easing the struggle to “prioritize”
A stark reminder of what happens when the response cannot match the speed of the situation is this new video from the U.S. National Transportation Safety Board. In aviation, the Commercial Air Safety Team (CAST) was created to avoid accidents. CAST’s award-winning progress was a fundamental shift.
In security, benefits of making the shift start with fewer ugly surprises, more actionable insight, and reduced time and cost. Your opportunity today is to shift to the right tools designed to move at the speed of the wild.
Brian Barnier Principal Analyst & Advisor, ValueBridge Advisors, USA
The evolution of data centers is affecting both centralized and distributed environments. As IT operations gain familiarity with server virtualization, security groups can evolve to best practices for secure server configurations in virtualized environments. However, simple server virtualization is only the start. Consider that:
Roles still need to be managed differently. Application delivery and provisioning change dramatically, altering how access control rules need to be crafted and implemented. The virtual data center begins to be a more sophisticated, elastic private cloud, and access rules need to move to the application level.
Experience with private clouds leads to demand for the use of public cloud services, in particular infrastructure-as-a-service (IaaS) offerings such as Amazon Web Services and EC2 and Microsoft Azure. The first wave is generally running development and test environments on public cloud services, but more applications, such as workforce and enterprise resource planning (ERP) programs, are being moved to cloud services providers as well. Access policies and monitoring controls can be extended out to cloud services, but the level of visibility and control varies widely across different flavors of public cloud. IaaS can provide a high level of both, but they are dramatically reduced when using many software-as-a-service offerings. Security architectures must be updated to extend out to cloud services, and security groups must be involved in the evaluation process to make sure that the cloud services meet at least the minimum needs for monitoring and control enforcement.
Demonstrated cost savings and faster time to market drive demand to move sensitive production services to public cloud, continuing the cycle. Security architectures need to scale in the same manner.
How do businesses embrace these transitions without creating inconsistent security controls and gaps in security policy? Read more about next-generation security in the recent SANS Institute whitepaper, “Conquering Network Security Challenges in Distributed Enterprises.”
The Apple Watch release in April was refreshing. As Google Glass and other “revolutionary” pieces of personal technology continue to come up short and experience developmental delays, it was nice to see Apple launch the first mass-market smart watch. However, along with innovative technology comes potential concerns. How will wearables in the workplace affect security?
Risks of Wearables in the Workplace
The biggest potential issue associated with wearables is that they are personal. They can go anywhere, with anyone, and contain large amounts of personal data. Many wearables continuously run and never stop gathering data and information—which makes them extremely valuable to the user, but also enticing to hackers and cybercriminals.
That is why businesses have to be smart with how they approach wearables in the workplace. Until wearables become more mainstream and commonplace in business, sophisticated security solutions likely will not exist. That means it is up to individual businesses and their employees to develop smart practices to avoid the following potential risks:
Data leaks—Perhaps the biggest risk is that smart devices (wearables included) store so much data. Just as hackers target smartphones, they will also go after wearables to access proprietary data and sensitive information. The problem for businesses is that every new device creates a unique entry point—making the risk of compromised data that much greater.
Violations of privacy—From an employee perspective, it is possible that data leaks coming from wearables could lead to personally identifiable information (PII) identity theft. According to the National Institute of Standards and Technology, this is “any information about an individual maintained by an agency.” Under that definition, private information refers to (1) anything that can be used to identify or distinguish a person’s identity (name, address, social security number, etc.) or (2) any information that can be linked to an individual (educational background, financial information, employment history, medical records, etc.). Because wearables gather so much personal data, a leak could result in serious PII identity theft.
Network security—As mentioned, for every new device, there is a new network entry point. For large corporations and enterprises, it will be virtually impossible to train employees for every situation. Even one oversight by a single employee could be enough to compromise network security.
Top Ways to Secure Wearables
So, how can businesses and employees band together to make wearables more secure in the workplace? It will take a major effort on the part of everyone and certainly will not be a minor undertaking. However, with the following tips, businesses should be able to get started in the right direction.
Additional layers of security—Security layers will be extremely important for wearables. This requires an effort from everyone—including app developers, hardware manufacturers and network administrators. By creating three layers of security—one on the physical device itself, one for each individual app and one on the device network—the risk of data leakage can be mitigated. Within each of these security layers there are various security options, including passwords, access control, biometric entry and more.
Data classification—On top of multiple security layers, companies should be cautious with the access they grant to employees. There should be specific classification levels and only employees that need certain data should have access. Systems can be programmed to only grant access to devices based on pre-established clearance levels.
Staying up-to-date—Businesses that choose to incorporate wearables into the workplace need to cautiously follow developing laws and regulations. Because wearables are so new, the rules surrounding them are constantly changing. Businesses must be careful with what information they collect and what data they protect. Otherwise, companies could find themselves in legal trouble down the road.
Educating employees on rules—Furthermore, businesses need to carefully relay information to employees. As is the case with any BYOD policy, employees need to know what information they can and cannot access via the device, whether certain apps are allowed to be downloaded, and when and where the device can be powered on.
According to Steven Bjarnason, a senior information systems security analyst for a Virginia-based cybersecurity services firm, “Businesses should already have information and network-security policies in place to cover many of the concerns applicable to wearable technology.” In other words, you cannot allow wearables and then develop a strategy for securing them.
Businesses already need to have answers to the following questions:
What types of wearable devices can employees wear?
Can employees purchase their own wearables or will they be company provided?
Can employees access business documents, data and information on these devices?
Are employees permitted to mingle personal and business data on the same device?
What type of information is determined to be personal?
For businesses that choose to allow wearable devices, these and other questions will become extremely important in the months and years to come. Where do you stand?
With an increasing number of connected cars coming onto the market over the past several years, it was only a matter of time until we saw a complete remote hijacking of a moving vehicle. This week, as reported by Wired, security researchers demonstrated the ability to wirelessly take control of a moving Jeep Cherokee from a remote location ten miles away.
The hack is accomplished by first connecting to the Internet via a wireless telecom provider. The hacker can then connect to any other device on that wireless network by way of a very relaxed security architecture. Once connected to a car, the hacker can exploit a vulnerability in the car’s software to take control of the vehicle’s dashboard functions, steering, brakes and transmission.
It’s estimated by the researchers that there are roughly 471,000 cars on the road that may be vulnerable to this kind of exploit.
The manufacturer of the vehicle featured in the Wired report just released a patch for this zero-day vulnerability, but it requires a clunky manual installation on each car. The unlucky owners of affected vehicles must manually install the patch via a USB stick or visit their neighborhood dealership. Many will not know they need to do this until their next visit to the automotive dealer, leaving them vulnerable in the meantime.
This type of discovery is, unfortunately, a frequent scenario that plays out in IT departments across the globe:
A new zero-day vulnerability is reported and hackers begin exploiting that vulnerability, resulting in many unfortunate victims. Security vendors issue signatures or updates to block or detect the threat and the vendor releases a patch. The patch is eventually deployed to close up the vulnerability, though inevitably there will be some systems that do not receive the patch for various reasons.
But what happens in an IoT scenario when that “thing” is your car?
A new zero-day vulnerability is reported and hackers begin exploiting that vulnerability, resulting in many unfortunate victims. Victims’ cars may begin to randomly accelerate or they might lose the ability to brake. Security vendors issue signatures or updates to block or detect the threat – but wait! There aren’t any security tools to update on a car. So the vendor releases a patch, and that patch is eventually deployed to close up the vulnerability, but inevitably there will be some cars that do not receive the patch for various reasons. In this scenario, each car will need to be manually updated. It’s not unlikely that many vehicles will remain vulnerable for years.
It’s now clear that an expanded perspective on security requirements needs to be considered well in advance of new Internet-enabled products hitting the market. In fact, our personal information, health records, corporate data, national security, public utilities, and now the lives of anyone riding in a connected vehicle all depend on us getting this right.
There are four key areas where the cybersecurity industry, network providers, and vendors of IoT products must fundamentally adjust their collective mindsets:
Detection vs. prevention: Many in the IT industry have been convinced that, because it’s so difficult to prevent advanced attacks, we should all give up and focus on detecting and responding to breaches. This does not translate well into the world of connected vehicles, and frankly, was never a good argument in the IT environment either.
Sure, it’s much easier to detect that something has already been hacked than it is to prevent it. By definition, you will have a much higher success rate if you focus on detection. So if you set out to maximize your success and then subsequently set the criteria for that success, you will inevitably choose detection as your objective.
On the other hand, if you begin with the noble goal of breach prevention, you face a bigger challenge, but you’re working towards something that will ultimately provide far more value, and in this case, could even save lives. That is our goal here at Palo Alto Networks. We provide a security platform that can prevent zero-day exploits without the need for updates or patches.
Patching vs. exploit prevention: Patching vulnerable systems and applications is a good practice, but it’s generally too little, too late. A patch will never protect you from a zero-day exploit, because by the time the patch is available, it’s no longer a zero-day. Exploit prevention technology, like that used in Palo Alto Networks Traps endpoint protection product, is key to preventing compromise via exploitation.
Open networks vs. zero-trust/micro-segmentation: The first step in hacking automobiles is to connect to the Internet via a publicly available wireless telecom provider’s mobile Internet gateway. The hacker can then scan for and connect to other devices on the network. Why is this possible? Shouldn’t there be restrictions in place to prevent the general public from connecting to a vehicle on that network?
I posed this question in 2004 when, as a then-security consultant, I was tasked with running a security risk assessment at a large telecom provider. It was just as clear to me then as it is now: allowing these connections to exist is risky business. During this assessment, I realized that an attacker or automated exploit could travel between customer IP addresses on the same gateway interface. Many customers expect a private mobile network with no inbound traffic allowed, and they may not be prepared for the possibility of worm infection or other attacks from outside networks.
The telecom provider in this case didn’t feel it was their responsibility to address this issue because their business is simply to provide an Internet connection.
At Palo Alto Networks we advocate for micro-segmentation and deep protocol inspection to ensure that only legitimate traffic is allowed and only to the correct places. We enable this with our next-generation firewalls.
Secure product architecture: Organizations must take a security-centric approach to the design of their Internet-enabled products. Rather than design based on how the productshould work, begin with the assumption that anything connected to the Internet will be at risk, and then design the product accordingly.
For instance, does your car need to be connected to the Internet at all times? Or should you have the ability to disconnect it when you prefer? Does the Internet-connected component of your car need to be able to communicate with the brakes, transmission, and other critical systems? Or can it be isolated to communicate only with the navigation, entertainment, and other conveniences that require Internet connectivity?
In the age of IoT, prevention is the only viable path forward. At Palo Alto Networks, we believe that our prevention-based approach to securing enterprise networks ought to be applied to every industry that deals in Internet-enabled products and devices. Our products enable enterprise customers to properly segment their network traffic, thereby allowing only legitimate users and protocols, and prevent exploitation of vulnerabilities.
We modeled the Cybersecurity Canon after the Baseball or Rock & Roll Hall-of-Fame, except for cybersecurity books. We have more than 25 books on the initial candidate list, but we are soliciting help from the cybersecurity community to increase the number to be much more than that. Please write a review and nominate your favorite.
The Cybersecurity Canon is a real thing for our community. We have designed it so that you can directly participate in the process. Please do so!
The Florentine Deception by Carey Nachenberg is a recently published novel grounded in cybersecurity. The book begins when cybersecurity expert, Alex Fife, is asked to clean up an old PC his father purchased at an estate sale, only to discover a piece of rather sophisticated malware that captures the user’s keystrokes and sends them to an email server in Russia. To Fife, this situation doesn’t compute; and after a bit of forensic analysis and some sleuthing about the PC’s previous owner, he determines that this system compromise is no accident. In his investigation, Fife also discovers a mysterious detail he can’t quite figure out – something about an item known as Florentine.
The Florentine Deception is a picaresque novel in that it follows Fife’s investigation from beginning to end. Through this journey, Alex gets increasingly engaged as his investigation evolves from the obsessive hobby of a rich, out-of-work technology executive to an international incident with potentially devastating national security implications.
While The Florentine Deception is most certainly a fun read, it also has educational value for cybersecurity professionals. The author is an experience cybersecurity professional and Symantec Fellow who certainly has in-depth experience with cyberattacks, and this knowledge is clearly evident in his descriptions of social engineering techniques, threat actors, and malware. Yet he is able to weave cybersecurity themes throughout the book without overwhelming less erudite readers with technical gobbledygook. The story also includes a credible, albeit frightening cyberwar-like conclusion. In this way, the book is enlightening and entertaining.
Cybersecurity professionals who enjoy reading books by authors like Dan Brown (Digital Fortress) and Mark Russinovitch (Trojan Horse, Zero Day) will find this book particularly worthwhile.
Review
As I walked across the halls of Moscone North during this year’s RSA Security Conference, I saw a friend from Symantec coming toward me, accompanied by another person. I stopped the pair in order to exchange pleasantries and discuss RSA happenings. That’s when I was introduced to my friend’s colleague, Carey Nachenberg, who holds the distinguished position of Symantec Fellow.
I can’t remember the exact flow of the conversation, but somehow, Carey mentioned that he had just published his first novel, The Florentine Deception and told me that, if I liked reading cybersecurity-centric fiction, I would thoroughly enjoy his book. Being an avid reader of all things InfoSec, I enthusiastically accepted this offer and responded that I would welcome the opportunity to peruse his first work. Nachenberg then took my card and vowed to send me a copy soon after RSA. About a week later, I received a FedEx package from Symantec, as promised, containing a paperback edition. I proceeded to motor through the entire book a few weeks hence.
The Florentine Deception is a first-person narrative about a cybersecurity professional named Alex Fife, and the entire story takes place in the Greater Los Angeles area of Southern California. While in college, Fife starts a cybersecurity company based upon a crowdsourcing model for anti-malware. Eventually the company gains market success and is then sold to the 800-pound antivirus gorilla, ViruTrax, for nearly $300 million.
After remaining with ViruTrax for a year subsequent to the acquisition, Fife leaves the company a rich man, but quickly finds that he is bored by his new freedom. He spends his free time partying with his techie friends and getting into serious rock climbing with another group, but something is missing in his life, and he longs for some type of new adventure.
Unbeknownst to Fife at the time, his life would take an unexpected turn, based upon a rather innocuous incident. Fife’s father purchases an old PC at an estate sale, hoping to donate it to a church charity. Alex receives a call from his dad, asking him if he will clean up the PC and bring it back to a state of usability – a mundane task for someone with his technical skills. Fife proceeds with this PC-recovery routine only to discover a piece of unknown malware on the system – a keylogger linked to a Russian email address.
Now most PC technicians would simply re-image the system at this point, but as a cybersecurity nerd, Fife can’t help but follow up with additional malware research, and a forensic investigation, to get a better understanding as to why this malware had found its way to an ancient PC acquired at an estate sale. He then proceeds with his forensic investigations and discovers the identity of the PC’s previous owner, a recently deceased antiquities dealer from nearby Malibu named Richard Lister, Fife’s combs the Internet to gather any intelligence he can about this person. When he stumbles upon a Los Angeles Times article with the headline, “Malibu Man Acquitted of Antiquities Smuggling,” Fife’s instincts tell him that this malware is no coincidence and he quickly suspects something bigger involving cybercrime or some type of Russian state-sponsored espionage. Through his investigation, he also learns of an item that seems to be at the center of the mystery, something with the name Florentine.
Alex is intrigued and becomes engrossed in discovering the identity, location, and personalities involved in this elusive Florentine, and thus, his exploration proceeds through a series of twists and turns that develop throughout the remainder of the book.
Fair warning to more impatient types: you may be unimpressed by the first few dozen pages of this book (as I admit I was) and wonder where all the cybersecurity intrigue is, but I assure you that it is worthwhile to keep reading. Through the course of Fife’s picaresque journey, his role evolves from that of a bored and wealthy technologist acting as amateur detective to a cybersecurity expert, deeply involved a potential national security incident. This evolutionary transition is what makes The Florentine Deception so entertaining. Just when you think you understand what’s happening and where things are going, Nachenberg takes you in a completely different direction, ending with a truly credible (and frightening) cyberterrorism/cyberwarfare scenario that will have any InfoSec devotee reading as fast as they possibly can.
It’s also worthwhile to note that, in addition to its entertainment factor, The Florentine Deceptionhas value as a vehicle for cybersecurity education, which is why I chose to review and expose it as part of the Cybersecurity Canon. First, the story takes the reader through the intricacies of things like social engineering, phishing, cyber-attacker tactics, techniques, and procedures (TTPs), computer forensics and advanced malware. Nachenberg does a great job of highlighting these cybersecurity topics without too much of a geeky description, helping to guide less technically savvy readers and keep them engaged. In spite of this writing style, however, cybersecurity professionals will appreciate the tasks, details, and workflow undertaken by the protagonist. This book is also built upon a foundation of international intrigue, realistic geopolitical relationships, and actual good guys and bad guys with distinct agendas from different countries, cultures, and belief systems. This makes the notion of cyberterrorism and cyberwarfare a convincing, yet engaging component of the novel.
Conclusion
I absolutely recommend The Florentine Deception by Carey Nachenberg to those who enjoy reading books by authors like Dan Brown (Digital Fortress) and Mark Russinovitch (Trojan Horse, Zero Day). In fact, Russinovitch’s books are good analogues to The Florentine Deception, so if you found them educational and entertaining (as I did), than this one is worth picking up. It is also worth noting that the Foreword section of The Florentine Deception was written by Eugene H. Spafford (“Spaf”), a leading InfoSec expert and longtime faculty member at Purdue University. If you know Spaf, you know that his contribution provides enormous cybersecurity “street cred,” making The Florentine Deception that much more enticing.
In closing, I mentioned previously that this book may be a bit slow at first, but readers will be rewarded for their patience and perseverance. I truly believe that curious InfoSec professionals will find The Florentine Deception fun and informative, making it a logical addition to the Cybersecurity Canon.
