Filed under: application security, Software Development
Surely and not-so-slowly, the concept of “internationality” is disappearing — at least in terms of the free exchange of information — and the tiny, expensive devices in our pockets and purses are leading the charge.
For end users, the benefits of global information access are as obvious as they are numerous, especially thanks to apps such as Word Lens that can make you feel at home almost anywhere. But for developers facing international audiences for the first time, globalization brings a whole set of problems packed into a single, powerful word: standards.
This is especially true where application security testing is concerned. While every mobile platform is built with some degree of localization for the international markets it’s used in, the nuts and bolts are largely the same. And that’s only one compelling argument for global standardization of application security practices.
Different Countries, Different Needs, Different Practices
None of this is to say all mobile software needs a homogenized approach. Country-specific software often takes on the traits of its developers’ culture. Anyone who’s seen an interface designed for use in Germany, for instance, will tell you software on that side of Atlantic tends to offer users a lot more options, often to the detriment of overall ease of use.
But security testing standards are different, especially when an app is designed for an international audience. Web- and mobile-app users everywhere might have varied needs and expectations when it comes to security and privacy, but they all have them. And though communication is usually the first line of defense here, the language gap can sabotage attempts at international security outreach. Though the math that runs our favorite mobile apps is universal enough, the language needed to apply it effectively is anything but.
To put all this another way, there’s a difference between theory and practice. Even if international companies want to get on board with uniform security testing standards, there’s still a big challenge: How?
Bridging the International Gap
The answer? Plenty of automation, for starters, and expert input when human intervention is required.
Agile accounts for a lot of the software being developed today, and automation is already a huge part of that process. Applying it to an international security testing standard just makes sense: The more aspects of your security management you can automate, the less time you’ll spend trying to bridge those aforementioned gaps.
Think about it. Unlike people, automated processes don’t need to spend time explaining the newest, most bleeding-edge concepts in security testing. Done properly, a single group of people in a centralized location can implement them anywhere. Behaviors can be analyzed, strings of code can be tested, and security standards can be enforced consistently across the globe, leaving little room for the language barrier (or lack of information, or any other number of security-related problems) to get in the way.
In a mobile-app scene where multibillion-dollar corporations and two-person garage groups work shoulder-to-shoulder in the same industry, this also democratizes security from a finance perspective. When all apps share the same focus on keeping end users and their data safe, every company has the opportunity to release safe software.
The second leg of our proposed solution is a preventative — as opposed to a prescriptive or reactive — outlook on security testing, administered by experts in the field. The same benefits of centralized knowledge apply regardless of language. Automation can take the sting out of a lot of the more common security issues by providing a consistent set of practices and procedures, but when exceptions arise, who better to deal with them at the international level than people who have dedicated their careers to security?
A Globalized Security Focus
As the old saying goes, “The world keeps getting smaller every day.” When companies the world over approach app security with the same mindsets and standards, the “wall” protecting their end users only becomes stronger. That creates a healthier market for everyone — which is a good thing, no matter what language you speak.
Photo Source: Wikimedia Commons
Enterprises are using more apps than ever, many of which are cloud-based. That’s according to a recent Forbes article, and — no surprise — this increased use comes with increased risk. Survey data found that 85 percent of all data uploaded went to apps that enabled file sharing, and, perhaps more worrisome, 81 percent of data downloaded came from apps with no encryption of at-rest data. It’s no shock, then, to see a push from IT executives for enterprise-wide security programs that vet and review any app created, used or purchased by a company. And yet companies in both the United States and the United Kingdom are struggling to stay at the forefront of AppSec initiatives. With enterprise apps presenting more risk than ever before, why the disconnect?
Apps don’t come from a single source. As revealed by a Veracode/IDG webinar, 43 percent of apps in the US were internally developed, compared to 36 percent in the UK. Both countries sourced 35 percent of their apps from commercial vendors, while UK companies outsourced slightly more apps to a third party (30 percent — the US outsourced only 25 percent). But that 25 covers some big-name enterprises — for example, John Deere. While the global farm-equipment maker won’t outsource the design of “customer experience,” according to CNBC, it has outsourced mobile device code. John Reid, the director of product technology and innovation at Deere, says, “We could take the stance that we need to know how to write all the apps ourselves, but that’s not what makes the difference to our customers.” It might, however, if that app code doesn’t pass basic security requirements.
The easiest way to reduce app vulnerabilities is to create an enterprise-wide security program. In the United States, 52 percent of company executives have mandated this kind of program and are tracking its implementation, while 32 percent are aware of such programs but haven’t made them mandatory. Results in the UK are more concerning: While almost the same number of execs are aware of these programs as in the US, only 38 percent have made them mandatory. So what’s the holdup? Why does the UK lag behind the US, and why are stateside businesses not 100 percent in favor of end-to-end AppSec?
Part and Parcel
There are two major hurdles that any company must overcome to implement this kind of holistic enterprise policy. First is an understanding of what testers are looking for when they analyze in-house, commercial or third-party apps. For example, the National Institute for Standards and Technology (NIST) is creating a mobile-application vetting guide (the current draft, “SP 800-163: Technical Considerations for Vetting 3rd Party Mobile Applications,” is available online or review and comment) to help companies identify potential vulnerabilities. In many cases, these vulnerabilities aren’t obvious. As noted by NIST Computer Scientist Tom Karygiannis, “Apps with malware can even make a phone call recording and forward conversations without its owner knowing it.” It’s also possible for apps to gain access to contact lists or track a user’s location. Without a set of best practices for analyzing and reporting application vulnerabilities, any enterprise-wide effort ends up being slapdash and ad-hoc, ultimately defeating the purpose.
The second part to this AppSec problem is the pipeline. With apps coming from so many sources and with so many cloud-enabled functions, it can be almost impossible for local IT professionals to catch and inspect each one. As a result, mandated security programs may fail not for lack of effort or guidelines, but rather from lack of resources. Due to this, it’s often worth partnering with an application security provider that can monitor, test and report on apps in real time — even when an enterprise is scaling to test hundreds to thousands of apps — and provide the framework for an effective, enterprise-wide initiative. Combined with a set of testing best practices like those from NIST, it’s possible to manage the app pipeline and ensure only “clean” applications come out the other side.
Businesses in the UK lag behind their US counterparts when it comes to application security, but companies in the United States aren’t immune to application risks. Intelligently managed, clearly defined and enterprise-wide AppSec is essential to reduce cloud-based application risks.
Photo Source: Bigstock
There’s a reason digital security and privacy concerns are more prevalent in the minds of end users than they’ve ever been. When your entire life is stored on a pocket-sized device designed to access other devices and networks, the thought of a stranger gaining access is horrifying. Personal photographs, bank accounts, private correspondences with friends and family — and all it takes is one person with the wrong intentions to take that info and do seriously bad stuff.
In this world of third-party apps and extended permissions, the problem is that no one company providing apps or services within an ecosystem is responsible for end-user security — everyone is. And when everyone is responsible for, well, everything, the high-level solution comes down to a word many of us love to hate: awareness.
Before you roll your eyes, let me explain. Recognition and awareness are not the same thing — we all understand security is massively important in the digital era. On the other hand, knowing that and knowing how to act on it are two very different things.
Take a look at Heartbleed. This vulnerability, which gained worldwide attention due to its ease of abuse and the amount of high-profile websites and apps afflicted, became possible due to a flaw in the hugely popular OpenSSL. This made it exploitable in almost all sites and services using the library. A patch is now available, but countless users are still affected and find themselves largely powerless — until they become aware of the problem and start implementing the fixes.
Bugs the size and scope of Heartbleed are rare. Still, if you’re a company whose product has been affected by issues, that doesn’t matter — nor does who’s ultimately responsible for the problem. While end users are more aware of the intricacies of software development than ever, even the quickest fix and most sincere apology won’t stop many from switching to competing products.
Seemingly harmless programs can require deep access into a system and, potentially, a user’s personal info. That access can allow others to do things the device’s makers didn’t intend, and that’s where problems often begin. The key is for executives and managers to give everyone in the organization the tools they need to avoid such oversights, especially when scaling to ensure security on hundreds of applications (or more) per year.
To truly get a handle on issues that could have a very negative impact on users’ lives (and thus the health of the developer’s business), both organization- and individual-level awareness are necessary. As we’ve said before, software development is a balancing act: too much focus in one area can cause serious deficiencies in another. That same thought applies to security.
Two Vital Elements: Education and Expertise
Reacting to issues as they arrive is no longer enough — assuming it ever was. On the contrary, it’s crucial for an organization to anticipate and avoid problems before they’re located.
Bringing in an expert on a case-by-case basis may fix individual problems, but that’s like fixing the symptoms instead of treating the disease — whenever new issues arise, the company’s in the same boat as before.
In our minds, the twofold solution to these concerns is awareness, achieved through:
- Early, Frequent Education: An organization is nothing more than a group of people. Bringing all those people up-to-date on the latest information and training makes sure the organization as a whole is covered before, during, and after any exploit issues.
- Expert Help: You can’t fix problems or incorrect practices you don’t know exist. Once teams are aware of the issues, bring in experts — not to analyze singular issues, but to enact long-term, organization-wide changes. It will be worthwhile, too, to consider a scalable, cloud-based security solution in order to make it easier for a small, internal team of security professionals to support developers across many teams.
To put this all another way, awareness isn’t just a buzzword to be blown off, especially in the context of security. Use these tips to stay on top of your game, because the alternative is far from appealing.
Photo Source: Flickr
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.