Maintaining focus is important, but priorities shift.
Those seven words sum up a conflict as old as time in the world of software development, where sharpening focus in one area inevitably causes a need for improvement in another. If anything, it’s a testament to the cyclical nature of development as a whole: Any change, from a shift in methodology to implementation of new technology, can cause problems (or benefits) bigger than the initial change was meant to fix.
As an example, consider the increasing tensions between time to market and security assessment, two monumentally important aspects of the development cycle.
While quality and speed have always been at odds to some degree, there’s no doubt that things are coming to a head now — or that, given current market conditions, developers of all sorts need a solution that doesn’t include pulling resources from one area to dump into another. Speed and security are the name of the game in every niche and submarket of the software-development industry, and woe be unto those who can’t find a decent balance before the bad guys do.
Sometimes the numbers say it all. IDG, a research company long known for its insightful findings, recently announced that over 60 percent of enterprise-developed web, mobile, and legacy apps aren’t checked for potential security issues. If that’s not an indication of the potentially damaging consequences of competing priorities, we don’t know what is.
Agile: Automated, Efficient — and Insecure?
Of course, the X-causes-Y relationship between speed and security is a very high-level take on things. The real-world issues causing these problems are far more nuanced, which can make isolating and resolving problems all the more difficult.
Take the Agile movement, a collection of practices and methodologies so popular that 88 percent of respondents (3,501 of them, to be precise) claimed to use it in a 2013 VersionOne survey. While the 2014 figures haven’t been released yet, it’s fair to assume they’ll be higher: last year alone, the number of Agile adopters rose 8 percent, according to the company.
Obviously, there’s a reason so many companies have chosen to at least dabble in Agile. Whichever of the countless variants you choose, you end up with a process/methodology much better suited to the realities of contemporary software use. Internal or customer-facing, an incremental approach allows you to fix issues and make improvements faster than traditional methods — a crucial distinction in this new age of small attention spans and instant gratification.
But there is a trade-off — or perhaps a sacrifice — required to make that adjustment, as evidenced by IDG’s 63-percent figure referenced above. As trends show the rise of the software application layer as the number-one attack vendor leading to security breaches, the ramifications of that sacrifice only become more serious.
As always, the problem lies in the dichotomy between speedy delivery and secure delivery. The sheer amount of time needed to ensure a secure product flies in the face of one core Agile tenet (speedy deployment), while a need for dedicated, generally specialized personnel can disrupt the practice’s focus on automation.
The Piecemeal Problem (and a Solution)
Internal security assessments aren’t always viable options for developers. Going ad-hoc presents similar issues: Besides being totally dependent on the skills and knowledge of the people performing the test, the prices companies pay for these manual tools tend not to align with the value or results they receive.
Instead, security assessments need to be integral parts of every plan. Moreover, the practices and processes behind them should be continually refined, improved and adapted. When every incremental update potentially opens the door to another breed of attack, patching and moving on is the equivalent of fixing tires only when they go flat — it’s just a matter of time until the lack of preventative maintenance causes trouble no quick fix can remediate.
Unfortunately, the inverse is also true in the ongoing struggle between getting a product out quickly and safely. We certainly aren’t trying to argue that speed isn’t an imperative factor — quite the opposite, in fact.
The secret? Finding that balance we talked about way back in the first sentence. This does not necessitate a trade-off, a sacrifice or any real loss on the other end, however. Even if your current projects are among that 62 percent, you can approach security assessment with an ongoing, distinctively agile mindset: think continuous, flexible, scalable and automated.
In an industry where surviving (and indeed, thriving) means fixing security problems every time they present themselves, it appears to us that finding trouble is almost always better than letting trouble find you.
Photo Source: Wikimedia Commons
Filed under: ALL THINGS SECURITY, Vulnerabilities
Facebook’s $50,000 award for research on static code analysis puts the focus on the importance of defensive technology – and that’s a welcome change.
We may have over-learned the lesson about the limits of cyber defense. However, Facebook’s surprise award of $50,000 to two researchers for their work on a new method for discovering vulnerabilities in web applications back on cyber defense – and that’s a welcome change.
I know what you’re thinking “Who says we’ve been under investing in cyber defense?” That’s fair enough. Defensive technologies do eat up most of the security budget -from endpoint protection software (aka “antivirus”) and intrusion detection. And regulations like PCI DSS – the Payment Card Industry Data Security Standard – concentrate almost entirely on preventative measures to protect sensitive data.
All that’s true. And yet, the last five years has seen the focus of private and public resources turned to what might be broadly referred to as cyber “offense.” We’ve been told over and over again that antivirus software doesn’t work (which is true) and that traditional perimeter-based protections like firewalls were necessary, but insufficient to stop stealthy, sophisticated attackers capable of using social engineering techniques and drive-by exploits of web browsers to gain a foothold on your employees’ computers and, from there, work their way to your company’s crown jewels.
In response, we’ve been admonished to think of attackers as “who” and not “what” and to research hacks to the ends of the earth – literally. We’ve poured resources into profiling of malicious actors, of the type firms like FireEye/Mandiant and Crowdstrike do. More broadly: the industry has poured serious cash into vulnerability research, with bug bounty programs from most major software firms and high-profile contests like Pwn2Own attracting worldwide media attention.
In that same period, investments in the kinds of tools and technologies that might make software applications less prone to hacking have lagged. For all the bug bounty programs, how many secure coding contests are there?
Part of that lies in the nature of the task. Discovering a serious software vulnerability is no easy task – it can require weeks or months of intensive focus. But it is a discrete task. A vulnerability is a vulnerability – and its easy enough to prove that its for real, or it’s not. But how does one go about rewarding the application developer for not creating the vulnerability in the first place?
Facebook took an important step in that direction this week when it awarded its first-ever Internet Defense prize to two researchers from Ruhr-Universität Bochum in Germany for their work on a method for making software less prone to being hacked.
The prize, $50,000, will be used to help the two further refine the tools they developed, which make it easier to find so-called “second order” vulnerabilities in web applications.
In a post on Facebook.com, John Flynn, a security engineering manager at Facebook, said that the prize money was intended to reward nuts-and-bolts security research on cyber defense that “prevents vulnerabilities and reduces the effectiveness of attacks.”
The Internet Defense Prize recognizes what Flynn called “superior quality research that combines a working prototype with significant contributions to the security of the Internet—particularly in the areas of protection and defense.”
As I noted over at Security Ledger, the winning submission, which was presented at the recent USENIX Security Conference in San Diego, improves analysis of untrusted data flows within web applications. The researchers, Johannes Dahse and Thorsten Holz, developed an automated method for collecting “all locations in persistent stores that are written to and can be controlled (tainted) by an adversary.” Basically, their analysis tool provides comprehensive auditing of data flows within a web application, but defers decisions about whether particular data flows are malicious until all “taintable writings to persistent stores are known.”
Chris Eng, Veracode’s Vice President of Security Research said that the prize is a good start.
“Bug bounties are becoming commonplace, and while they provide tremendous value, they focus on offensive work – find a security flaw, patch it, repeat ad infinitum.”
Over time, that kind of hunt-and-fix approach does improve the security of the product through tactical refinements. But defensive technologies are more strategy than tactics, he said. “They seek to either make exploitation more difficult or to identify and eradicate entire swaths of flaws at once.”
Eng notes that Facebook isn’t the only company to put their resources behind better defense. Microsoft’s BlueHat Prize has been a major bounty for defense in recent years. But the more the merrier – especially with so much work to be done.
It’s tempting to imagine your supply chain as one unbroken line where each link is directly fastened to the next, making it easy to uncover weak spots or add new processes. In truth, this chain more closely resembles a tangled web with lines and links that branch out, interconnect and then split. The recent Target breach, for example, began with stolen credentials from a third-party HVAC vendor, and in a market where suppliers and partners may be half a world away, IT operations professionals face the immediate task of developing a new paradigm for supply chain security.
Let’s take a look at what happens when breaches go global, plus best practices for handling the threat.
A recent article in Forbes discusses partner networks — a major sticking point for the supply chain. In the piece, author Dave Lewis recalls a penetration test of the 300 partners connected to his business’s network. In less than 15 minutes, the network had been breached via a third party using “$vendor” as both its default username and password. The test uncovered a sobering statistic: less than one-third of all the company’s partner connections had any documentation concerning their access policy. Most of those with documentation, meanwhile, provided data that was incomplete at best.
With traditional supply soft spots locked down, the global sourcing of raw materials and labor has created a massive, though immature, digital supply chain. As a result, network connections are the new battlegrounds — and one weak link can spell disaster.
Rules and Regulations
Not all supply chain security threats come from outside. As noted by Supply Chain Digital, new legislation can prove costly if businesses don’t have agile security measures in place. Why? Because legislation, like the Office of the Comptroller of the Currency (OCC) bulletin 2013-29, places the onus squarely on companies for managing the risk of any third-party interactions. For example, a financial institution is now expected to establish “risk management processes that are commensurate with the level of risk and complexity of its third-party relationships” — in other words, “arm’s length” isn’t a good enough reason for a security breach. In addition, rules around “conflict minerals” are being tightened, meaning companies need hard data to prove where materials like gold or titanium are sourced, and demonstrate that operations adhere to all local and international supply regulations. At best, poor compliance and visibility slows global supply chains to a crawl as regulatory headaches prevent the movement of raw goods. At worst, entire chains collapse under their own weight.
Beyond partner connections and evolving legislation lies the essential framework of any digital supply chain: software. On average, two-thirds of the software used by an enterprise comes from third parties, and of that software, Veracode’s State of Software Security report shows that 62 percent fail basic security standards, and 90 percent fail to comply with the OWASP Top Ten. It gets worse: technology news site V3.co.uk notes that according to a study by security firm Secunia, 86 percent of security vulnerabilities reported in 2013 existed on third-party apps. The result is a simple trail for hackers to follow, especially when servers and networks aren’t within reach. Think of these as correlated variables: greater distance requires improved supply chain security.
To manage the threat of global supply chain breaches, two best practices emerge. The first is developing a real-time, working knowledge of all third-party connections and applications linked to your enterprise. This is a daunting, yet necessary task — since compliance lawmakers are no longer willing to accept “arm’s-length” arguments as valid defense, when violations occur, oversight due to ignorance or distance won’t excuse them. Beyond knowledge is the second best practice: action. The sheer number of partner connections and third-party apps in use often makes such granular management impossible without the aid of an experienced vendor and a programmatic approach. You’ve seen it in other areas of IT compliance: ad-hoc, moment-of-crisis security solutions yield short-term results but can’t deliver protection for an entire network. This is especially true at the global supply chain level, where the massive warren of resources, parts and manufacturing interconnections lead IT down the rabbit hole, desperately trying to solve one problem, even as three others emerge.
Global supply chain security requires forethought, total network visibility and the benefit of a “monster in your corner” — that is, a provider able to assess and remediate poor access policies or badly written code entirely from the cloud. Bottom line? The supply chain is changing, and security can’t stagnate.
Photo Source: Bigstock
Filed under: application security, Third-Party Software
Supply chain management may conjure thoughts of enterprises driving business relationships with an iron hand – think of Walmart’s legendary purchasing power driving innovation into its suppliers. But some supply chain transformations occur through collaboration between the supplier and the enterprise in support of meeting the enterprise’s goal.
In green supply chain transformations, there are examples of this both in the formulation of environmental guidelines and in developing practical solutions to environmental challenges. The same can be seen in secure supply chain efforts. Some of the innovations in Veracode’s VAST program, such as vendor on-boarding and scoping calls, have come from supplier suggestions. Better still, the frame of VAST itself, in which suppliers are required to reach compliance with a policy and given latitude about how they test and correct issues to meet that policy, encourages collaboration between supplier and enterprise.
Veracode’s own VAST offering is a good example of collaboration between enterprises and vendors. Enterprises wanted the ability to understand the security of their purchased software, as they understood that vulnerable third-party applications put their data at risk. Software vendors had two concerns: they didn’t want enterprises to have sensitive data that could risk their IP, and they didn’t want to do bespoke assessments for each supplier. The outcome of the desires of both parties has been the Veracode VAST model. By choosing to work with Veracode for a security attestation, software suppliers can provide the needed proof of security to their customers and prospects, while still protecting their data and intellectual property.
As you work to secure your supply chain, you should be mindful of the partnership between you and the software supplier. By presenting software security as a common goal, you will gain better acceptance and adoption.
The Seven Habits of Highly Effective Third-Party Software Security Programs
- Choose the right suppliers
- Put your efforts where they do the most good
- Use suppliers as force multipliers
- Collaborate to innovate
- The elephant in the room is compliance
- Drive compliance via “WIIFM”
- Align benefits for enterprise and supplier – or pay
It’s all over the news lately: new, flashy apps make it out of the oven, get great press coverage—and are hacked days later. Even the satirically simple app Yo, which sends a “Yo” message to a user’s friends, was a victim. In many cases, app developers could have easily avoided massive blows to their reputations by taking planned approaches to application security.
Following a preemptive strategy is the best way to arm your app against external threats that can compromise users’ security. Take steps to ensure your app is secure before its release—this will help you build trust with your users and save you from unnecessary risks on your investment.
Code audits have become integral to the product development cycle. While it’s one thing to test an app for potential bugs by having users give it a beta run, an in-depth code audit is really the only way to evaluate an application against the types of attacks that seasoned hackers will almost certainly attempt when it hits the mainstream.
An application security audit is the process in which a team of code auditors (usually former hackers themselves) comb through an application’s codebase and perform a series of checks, such as:
- Is the code doing something it shouldn’t be doing?
- Can the code be coaxed to do something fishy?
- Is the app transmitting user-sensitive data in the clear?
- Have programmers implemented security precautions appropriately?
Aside from these manual checks, audits can include automated testing for security issues. “White box” automated testing looks at the application from the inside checking to see if hacker inputs can make the application behave in odd ways. “Black box” automated testing looks for issues while the application is running. Applications can also be fuzzed, meaning it is subjected to massive loads of randomized inputs in order to see if it can handle them without crashing or compromising a user’s device or information.
It’s important to run a code audit on any application before its release, as security bugs can’t be caught by beta testers (who are more likely to find general usability problems). An app’s original programmers themselves can’t be reasonably tasked with finding security bugs in their own code, either—these bugs almost always need another team’s perspective in order to be discovered.
After an app has had its initial audit, results are communicated back to its developers, who will typically need to fix an issue or two before the app is published. It’s perfectly normal for audits to find bugs—in fact, bug-free audits are almost never good signs. Once that app is published, an annual audit ensures that added features are also checked against bugs. Auditing early, and often, is not only an intelligent way to save yourself from risking your investment, it’s a concrete testament to your devotion to user security, especially as privacy concerns become increasingly mainstream.
Consider Open-Sourcing Your Code
If your app offers users advanced security features such as data encryption or anonymity, it’s definitely worth asking your team to open-source the application’s code by posting it online for other programmers to evaluate. In the security community, open-sourcing security-critical code is a tradition that gets more eyes on the code to evaluate it and help decide whether it’s trustworthy. It also gives you free audit hours and, more importantly, builds your credibility with other programmers in the tech community.
Photo Source: Flickr
It’s becoming evident that modern enterprise executives understand the importance of application security (AppSec). Despite this, however, only a very small percentage of applications undergo a true security vulnerability assessment, leaving the majority wide open to attack. Enterprise executives who understand the importance of AppSec must learn how to secure both new and existing apps, along with develop a solution that makes it simple to keep them secure going forward — even when scaling to test hundreds to thousands of apps per month.
The Gap in Enterprise-Wide Application Security
A joint study with CSO and IDG found that executives are more focused than ever on ensuring their applications are secure. The study surveyed US executives and determined that 52 percent of enterprises have mandated an enterprise-wide application security program, which marks a significant improvement from similar surveys in previous years.
This shift in executive thinking is likely due to both the visibility that application security issues have received in the past year and the fact that even after these executives have shored up the access points and physical infrastructure, hackers and thieves are able to gain access. Applications don’t have to be weak points in an enterprise’s network, but if they are never tested for obvious vulnerabilities, they can act as open doors.
Despite these facts, and despite the renewed attention that AppSec is getting in the C-suite, only 36 percent of enterprise-developed applications go through a security vulnerability assessment to determine if security holes exist, and less than 10 percent of enterprises are ensuring that all critical apps are tested during production. With almost two-thirds of applications currently untested, and the ease of development putting new applications into play every day, there’s little wonder why one business after another suffers data thefts or system attacks.
The good news is that businesses appear ready to address these problems: The survey found that 70 percent of US businesses expect to increase their spending on security over the next year, a number that jumps to 80 percent when only large enterprises are considered.
Delivering Necessary Application Security
Given how few internally developed applications have been properly tested, executives may fear that true AppSec on thousands of existing apps is unattainable. But ensuring enterprise-wide application security isn’t impossible, even for large enterprises with dozens or hundreds of development teams.
Chief information security officers (CISOs) and managers must begin by getting an understanding of the development teams, what type of applications they are working on and their respective cycles. This can be a fairly large undertaking, especially since some teams may have adopted an Agile development paradigm while others remain on a legacy waterfall system. Once this list is in place, use it to create an overall security policy that takes into account the needs of all the apps in development. This way, the policy remains consistent and doesn’t have to be built from scratch each time the AppSec program expands to a new team.
Taking into account these four points will allow CISOs to find a security solution that fits their needs:
- Scalable: A cloud-based program can effortlessly grow as more development teams are added.
- Centralized: A security policy runs more smoothly when it is managed and updated from a single dashboard.
- Intelligent: It should learn as it scans and utilize the power of the cloud to recognize and check for new threats as they emerge.
- Has a binary static testing option: The solution must be able to scan apps that are still in development and which contain third-party code.
Roll out the solution to a handful of development teams to begin with, creating a subset consisting of those working on mission-critical apps and those with timetables allowing them the flexibility of adding new steps to their software development life cycle. As these teams find success with the program, and as the enterprise becomes more secure, this small series of wins will make it easier to scale up the program to the entire enterprise. Once all the development teams are on board, the same program can be expanded to provide a security vulnerability assessment on existing apps, eventually ensuring that the entire enterprise and thousands of apps are secure.
If enterprise executives want to get serious about enterprise-wide application security, creating a solution around these practices will provide the best opportunity for success. Plus, when the right cloud-based solution is in place, scaling up as application needs increase or shifting gears as the threat landscape changes is remarkably simple and ensures that the entire stable of applications remains secure in the coming years.
Photo Source: Flickr
Nothing says ‘yawn’ like the topic of insurance. One notable exception may be the mushrooming marketplace for cyber risk insurance. But do insurers really know what they’re underwriting?
Nothing says ‘yawn’ quite like insurance – and I say this as the son of one insurance salesman, and the brother of one more. After all: the insurance industry exists to manage risks: steering the ship of our lives in a calm and even path through the vicissitudes that make life exciting.
So bland is the insurance business perceived to be, that it’s the stuff of Hollywood comedy. In the 2004 film Along Came Polly, Ben Stiller played a skittish, risk averse insurance adjuster with actuarial data on bathroom hygiene at his fingertips (no pun). Woody Allen famously depicts his hapless criminal Virgil Starkwell locked in solitary confinement with an eager insurance salesman as in the 1969 mocumentary Take the Money and Run. Cruel and unusual punishment, indeed.
Boring though it may be, insurance markets are incredibly important in helping society manage risks of all sorts. Insurance markets also have a funny way of shaping behavior – both personal and commercial – in ways that serve the public interest.
Take the response to Hurricane Sandy as just one example. Law makers in Washington D.C. may never agree on whether that storm was a product of a warming climate. In fact, they may debate the ‘facts’ of climate change from now until the end of time. But property owners and businesses in that storm’s path are already adjusting to the reality of a more volatile climate – moving critical electric, environmental- and building management systems onto higher floors. And they’re doing so because of pressure from private insurers to mitigate future risks from flooding and storm related damage.
Many of us would like to see the same thing happen with cyber security – especially given the justified concerns about regulating an industry as dynamic as the tech sector and (more immediately) Washington’s difficulty passing even straightforward legislation. (Highway funding, anyone?) A wider reliance on cyber insurance to hedge risk may well have the effect of enforcing best practices on organizations across industries – from authentication to application development. That would replace today’s variable and ad-hoc approach to security, in which each company is left to survive by its own wits.
And change is happening – slowly. Target Stores, the box retailer that was the target (pun) of a major data breach last year reportedly had $100 million worth of cyber insurance coverage through a variety of separate policies. That money has helped to offset the monetary damage of the breach and spurred other companies to look for ways to hedge their cyber risk as well. The firm Marsh & McLennan estimates that the cyber insurance market could double to $2 billion in 2014.
But as Reuters reported recently, insurers are having a difficult time getting their arms around cyber risk. And that threatens to hold back the entire cyber insurance market at a critical time.
As you can imagine, insuring cyber risk is very different from insuring lives or automobiles – and potentially a lot more risky. For one thing, insurance companies have scant experience with and knowledge of “hackers” (broadly defined) – especially compared with the decades of data they have on driver behavior and automobiles. Not understanding how the thing you’re insuring against might behave leaves insurers on the hook for damages they might not have anticipated (and priced into their policies).
Why is that? Policies are often written based on the insured’s attention to standard defensive measures, rather than the findings of comprehensive security audits, Bryan Rose, a managing director at Stroz Friedberg told Reuters. That’s a big problem. As we know only too well, the gap between threats and defenses is wide and getting wider every day. As Target illustrates, questionnaires that fail to address third-party risk will also omit a major avenue for successful attacks.
More to the point for this blog: insurance firms that fail to take a hard look at application security, both in third-party products and in the internally developed applications will find themselves skating on thin ice, risk-wise.
As we know, many of the largest and most damaging data breaches come by way of attacks that exploit common and avoidable application vulnerabilities like SQL injection and Cross Site Scripting. Insurance firms that want to manage their risk need to have a strong foundation in application security, as well as the tools and talent to spot vulnerable and shaky applications – if not to ferret out specific, exploitable holes.
This will be a painful transition for both insurers and their customers. Insurers will almost certainly take more baths in the wake of major breaches, as it appears they did in the Target incident. And companies seeking to hedge their cyber risk will need to do more than check the box next to “firewall,” “antivirus” and “intrusion detection.” They’ll have to lay bare both the protections they rely on and the security and resiliency of the applications they’re protecting.
In the long term, however, the entire society will benefit from wider adoption of cyber insurance. The public- and private sectors have pursued countless strategies to address this endemic problem. Lists like the OWASP Top 10 or the SANS Top 20 have long highlighted the most serious and common problems, with little to show for it. As companies look to manage cyber risk, and insurance companies step forward to help them do it, we’ll begin to create structures that internalize the true costs of cyber security for society. That process will bring short term pain all around. But it will also produce long-term gains.
There is no greater threat to information security than the belief that systems are secure when, in fact, they are anything but. The growth in popularity of custom app development over the past few years has created a situation where many enterprises have thousands of applications in production with little or no security testing behind them—and most executives have no idea these security holes even exist. Enterprises concerned about information security must find a way to integrate sufficient testing into the software development life cycle (SDLC) to ensure their systems are as secure as possible.
The Ongoing Threat from Custom Apps
The average enterprise has come to use thousands of custom apps on a daily basis. The problem? Many of these organizations have no idea how many custom apps they are using, and it’s impossible to secure apps that IT management doesn’t even know exist.
What’s worse is that even the best AppSec programs are only testing approximately 10 percent of their apps, according to Aspect Security. As a result, 54 percent of breaches come through custom apps—a number that will only increase in the coming years, given such conditions as lax security and the growing number of available apps.
Custom apps are particularly vulnerable to hackers and thieves because they represent the path of least resistance. They are constantly exposed to the Internet (which makes them easy to probe for vulnerabilities), are developed quickly with little regard for in-development security and are assembled from a variety of code and library sources. In addition, they represent larger attack surfaces than traditional targets.
Securing App Development in an Agile World
In order to tackle the growing issues with custom apps, IT executives have to embrace a holistic approach throughout the entire SDLC while avoiding the additional expenses incurred by extra IT staff, consultants and infrastructure.
Through a discovery process, IT can take an exact inventory of all the apps they need to secure, granting organizations a handle on their existing app pool. From there, a massively parallel scan will quickly identify highly exploitable vulnerabilities, like those in the OWASP Top 10, and allow IT to segregate questionable apps until a deeper scan can be done.
Once IT has a grip on existing apps, an enterprise has to turn its attention to the development process and find a scalable solution that works from early code development right through production, especially in the fast-paced world of agile development. Implementing static application security testing (SAST) early in the development life cycle will allow IT to find many vulnerabilities, such as cross-site scripting or SQL injections issues, as well as coding errors, at a stage when they should be easy to fix. Because SAST works with binary code to find paths through an application, it can also be used with third-party software or libraries that exist in many modern custom applications. As the app-development phase moves to QA, dynamic application security testing (DAST) should be conducted to ensure that additional vulnerabilities aren’t exposed by the addition of a web interface. Finally, manual penetration testing has to be done on all critical apps, and the test results from every stage of development need to be centralized in a comprehensive solution to minimize false positives and help ensure overall accuracy.
The threat posed by custom app development is only going to increase in the coming years, as these apps will make up more and more of the overall network infrastructure. Enterprises that are serious about network security have to begin taking steps to mitigate problems today. The right solution has to be comprehensive, scalable through the cloud, and designed to discover both the security issues of today and the potential security flaws that hackers may exploit tomorrow.
Photo Source: Flickr
Nude photos of various celebrities were leaked to all corners of the Internet a few short days ago. You already know that by now.
Thank you iCloud
It goes without saying that all IT organizations should have an active Incident Response (IR) Plan in place – i.e. a policy that defines in specific terms what constitutes an information security incident, and provides a step-by-step process to follow when an incident occurs. There’s a lot of good guidance online about how to recruit a data breach response team, set initial policy, and plan for disaster.
For those organizations already prepared for IT incident response, be aware that best practices continue to evolve. The best IR plans are nimble enough to adjust over time. However, when the incident in question is feared to be a possible data breach, organizations should add a couple other goals as part of their comprehensive Application Security disaster planning:
- The complete eradication of the threat from your environment.
- Improved AppSec controls to prevent a similar breach in the future.
Veracode’s Information Security Assessment Team, which put together our own IR playbook, recommends that IT groups follow these five emerging guidelines to plan for the reality of today’s risks and threats.
1. Plan only for incidents of concern to your business.
According to the SANS Institute, the first two steps to handling an incident most effectively are preparation and identification. You can’t plan for everything, nor should you. For example, if no business is conducted through the organization’s website, there is probably no need to prepare for a Denial of Service attack. Companies in heavily regulated industries such as financial services or healthcare receive plenty of guidelines and mandates on the types of threats to sensitive and confidential data, but other industries may not enjoy similar “encouragement”.
Ask yourselves the question, what is OUR threat landscape, why would hackers and criminals want to attack us? The possible answer(s) will lead to a probable set of root causes for data breach attempts. Focus on what’s possible, but also don’t be afraid to think creatively. The U.S. National Security establishment was famously caught flat-footed by the events of 9/11 as the result of a “lack of imagination” about what terrorists were capable of accomplishing. By constantly re-evaluating your organization’s threat landscape (and by relying on solid threat intelligence to identify new and emerging threats), your data breach response team will remain on its best footing.
2. Don’t just plan your incident response, practice it.
Practice: it’s not just the way to Carnegie Hall. IR Plans must not be written and then left on the shelf to gather dust. A proactive and truly prepared information security organization educates its IT staff and users alike of the importance of regularly testing and updating breach response workflows. Plans must be drilled and updated regularly to remain viable. Even if it’s simply around a conference table, run through your response plan. Some organizations do this as often as monthly; your unique industry and the probable threats it faces will determine the ideal frequency of this best practice. At Veracode, we run regular Table Top Exercises on a number of possible scenarios.
The worst mistakes are typically made before the breach itself. Be prepared. The purpose of IR drills is to ensure that everyone understands what he or she should be doing to respond to a data breach, quickly and correctly. A good rule of thumb here is that “practice makes better, never perfect.” It pays to be honest about your IR team’s capabilities and their ability to effectively neutralize the most likely threats. If the necessary skills don’t exist in-house, then better plan to retain some outside help that can be standing by, just in case.
3. In speed of response, think “minutes” not “hours”.
IR teams should always strive to improve response times – that’s a given – and “within minutes” is today’s reality. On the internet, a service outage of more than one hour is considered significant. Social media chatter can very quickly amplify the damage that could be done to your business, so get out ahead of the crisis …and stay there.
SANS Institute defines the third step in breach response as “containment” – to neutralize the immediate threat and prevent further damage to critical or customer-facing systems. Move quickly to determine the possible severity of the data breach and then follow the customized response workflows in place for that scenario. To borrow some terminology from the military: is your “situation room” responding to a Defcon 1 attack or more like Defcon 5? Even as your IR team moves to eradicate the threat, you can be communicating to key stakeholders appropriately – according to the reality of the situation at hand.
4. Don’t over-communicate.
This guideline seems counter-intuitive. Sharing is caring, right? Wrong. Especially when it comes to the fate of your organization’s confidential or sensitive customer information. Your initial notification to customers should almost immediately follow detection as a pre-planned rote response. There will be no time to wordsmith the perfect statement in the thick of battle; better have it pre-packaged and ready ahead of time. That being said, this statement should be short and concise. Acknowledge both your awareness of the incident and the IR team’s continuing efforts to safely restore service, as soon as possible.
After that, plan to give updates to all stakeholders on some kind of methodical basis. Act like the NTSB after a plane crash. They give regularly scheduled press conferences on what they know so far, while firmly pushing back on what they don’t. Think like an investigator and deal in facts. Don’t speculate as to the root cause of the breach or even when service will be restored, unless that timeline is precisely known. Your communication to the market, while measured, should always be sympathetic and as helpful as possible. One final piece of advice: tell your customers the same thing you tell the media. There are (few if) no secrets left on the Internet.
5. Focus on restoring service first, root cause forensics later.
The root cause of a data breach incident is typically not immediately known, but that should be no impediment to your restoring service ASAP for customers (once the threat is contained and destroyed, of course). Keep the focus on the customer. Get back online as quickly as possible. Clearly, SANS outlines “recovery” as the step that ensures that no software vulnerabilities remain, but…
Ignore the engineers & analysts who want to investigate root cause immediately. With today’s sophisticated attacks, this can take weeks or months to determine, if at all. Still, incident response is not over when it’s “over”. As we’ve asserted, the best organizations – and their IR teams – take the time to learn from any mistakes. Monitor systems closely for any sign of weakness or recurrence. Analyze the incident and evaluate (honestly) how it was handled. What could be improved for better response in the future? Revise your organization’s IR Plan, making any necessary changes in people, processes or technology for when or if there is a next time. Practice any new workflows again and again until you know them cold.
Solid IT risk management strategies include disaster recovery planning and the creation of a living, evolving incident response playbook. Today’s IR plans need to be focused, factual and fast. Every organization needs to budget for the hard IT costs associated with data breach recovery. However, a comprehensive and battle-tested plan will help mitigate the “soft costs” associated with poorly handled data breach incidents. These can include lingering damage to revenue, reputation or market value – long after the initial crisis is resolved.