Picture this: You’re enjoying a beautiful summer Saturday, watching your kid on the soccer field, when your phone rings. It’s work. Bummer. “Hi, this is Ben from the InfoSec team. It appears that John Doe, whose last day is next Friday, just downloaded the entire contents of his work hard drive to an external drive. Given his role, there’s a high probability that it includes confidential and sensitive employee data.”
There goes your Saturday.
It happened to us—it’s probably happened to you This happened to us at Code42 a few months ago. A longtime employee was coming up on his last day, and innocently wanted to take years of work with him. We’ve all probably done this—grabbed some templates and examples of our work to use in our next chapter—and instead of sorting through years worth of work, it’s just easier to copy the whole drive. Unfortunately, this is against company policy and puts the company at risk. And in this case, there were confidential and sensitive files related to company personnel.
Not all data theft is malicious, but it’s still dangerous Of the fifty percent of departing employees that take sensitive or confidential data—most are not malicious. Some don’t know the rules; some don’t follow the rules; and most see no harm in their small actions. At Code42, we’re fortunate to have great people, and they have good intentions. But even the best intentions can have terrible consequences, especially when it comes to enterprise data security.
Too often, “innocent” data taken by employees inadvertently includes sensitive corporate data such as financial information, employee data, trade secrets or even customer information. There are risks and costs associated with leaked data; but knowing what was leaked and where it is greatly reduces the risk and damages.
Code42 CrashPlan avenges data theft—saves the weekend Back to the sunny soccer field, where I might have spent horrible moments dreading the fallout from this particular data pilfer, I make a single phone call and spend no time worrying about the cost of tracking down or trying to recreate lost files or deal with a potential breach.
With Code42 CrashPlan, I have complete certainty that all of this employee’s endpoint data is backed up, down to the minute. And I know our InfoSec team can tell me what the data is, what was copied and where it was copied to—down to the serial number of the external drive.
Modern endpoint backup: Sees what data you have, and it knows where it goes From there, the resolution is quick and—while it sounds dramatic—painless. A company representative contacts the departing employee, explains that we observed the content of the hard drive has been copied to a drive and requests return of the drive to Code42 on Monday morning. The employee promptly returns the drive.
And the best part of the story, I enjoyed the rest of the weekend, without the threat of data theft clouding the summer sky.
This is the power of modern endpoint backup. No matter where insider threat comes from—malicious lone wolves, employees conspiring with external actors, or well-intentioned, accidental rule-breakers—modern endpoint backup sees it all, in real time.
The vendor risk assessment is the lynchpin of every effective third-party risk management program. In theory, the essential components of an assessment are easily determined. However, in practice, the ability to effectively understand and assess third-party controls usually conflicts with the resources available to perform the assessments, and is further handicapped by the need to rapidly conclude assessments so contracts can be finalized and projects begun.
All too often this results in assessments that are performed based on resource availability and time rather than an appropriate review of required security controls.
Adding additional complexity is the growing pressure to expand third-party assessments. Regulatory agencies have significantly increased third-party assessment requirements. The U.S. Office of the Comptroller of the Currency (OCC) now requires companies to look at the entire vendor lifecycle when managing third-party risk (OCC 2013-29). The U.S. Federal Financial Institutions Examination Council (FFIEC) recently added the requirement that companies include an assessment of their vendors’ business continuity programs as part of the assessment process (FFIEC Examination Handbook, Exhibit J). Healthcare regulators have also joined in requiring a thorough security risk analysis as part of the HITECH Act/Omnibus rules.
Industry standards are also increasing the focus on third-party security. PCI DSS 3.0 (12.8.2) and the latest versions of ISO 27001/2 require a comprehensive assessment of third-party security controls. NIST also requires that third-party information security risk be evaluated for NIST compliance (SP 800-39).
The very practical need for thorough third-party assessments is the fact that third-parties are increasingly targeted by criminals, and continue to be the primary source of breach incidents. Rather than attempt to breach the systems of large and usually well protected company networks, criminals look for the weakest link in the chain, which is all too often a third-party.
The growing demand for more comprehensive third-party assessments necessarily requires expanded resources, budgets and timelines for completion. These needs run contrary to very real budget and staff constraints, and the pace at which business units need to bring new (often web/cloud based) products and services to market. So, how do you satisfy the growing demand for more comprehensive assessments of third-party risk controls without substantially increasing the cost and time for conducting assessments?
The first step is to fully understand your assessment workflow, and identify all of your information requirements, both internal and external. Then identify those activities that are extremely manual in nature. The simple truth is that it is difficult, if not impossible, to effectively manage assessments in a manual environment. From initiating and collecting assessment information, to managing your workflow and providing a centralized repository for all assessment-related activities, there are a number of industry applications that can automate the assessment process and provide significant relief for overburdened processes and resources.
Also, make sure that you don’t reinvent the wheel. There are a number of existing assessment frameworks you can use to refine or jumpstart your program. NIST, Health Information Trust Alliance (HITRUST), and PCI all have framework controls and questionnaires.
To learn more, join us on 26 July for an ISACA webinar, titled Effective Third-Party Risk Assessment – A Balancing Process, on how to manage all of these competing requirements and develop an effective program for third-party assessments. We will discuss how to find the best methods to balance these competing demands, and key ways to enhance your assessment process so you can do more comprehensive assessments without increasing the time and cost of assessment due diligence.
Brad Keller, Senior Director of Third-Party Practice Lead, Prevalent
Have you heard the story about the foolish farmer’s new horse? The story goes that one day in early spring, a farmer’s horse dies. The farmer needs a horse to pull his plow, so he goes to market to buy a new horse. There he meets a neighbor who says, “I have a promising yearling [adolescent horse] that will be up for sale in a month or two. Why not wait? The yearling will be much stronger and healthier than some old nag you’d buy here.” The farmer agrees.
A few months go by, and on the way to bring the yearling to market, the neighbor tells the (still horseless) farmer, “I have a foal—born just this season—that will be the strongest and healthiest of all my animals. Much stronger than this yearling if you wait a few more months.”
The farmer once again agrees, and as the harvest time is coming to a close, the neighbor comes again, this time saying, “I’ve found a stallion that will surely sire the strongest line of horses this town has ever seen…” The farmer stops him and says not to bother because, “Without a horse, I could not till. Without tilling, I could not reap. Without reaping, I could not lay stores. And without laying stores, I won’t survive the winter.”
The point of this parable isn’t hard to understand. Specifically, while future opportunities are great, it does not matter if you are not handling the critical needs of today. It’s a balance between the advantages of what you might get in the future against the “opportunity cost” of taking action right now.
This is a useful principle for practitioners making risk decisions for their firms. For example, consider a new technology, new application or new business process. There’s often a temptation to focus almost exclusively on the new risks such changes might introduce. But what about the risks offset by that change? What about the business risks in failing to adopt (i.e., if we don’t adopt and our competitor does)? The holistic risk equation is more complicated than it might seem on the surface, and saying that something new is “risky” is really only accounting for one half of the equation.
Mobile Payment Opportunity Costs?
One noteworthy example of this phenomenon right now involves mobile payments. Specifically, we know that many technology professionals are extremely leery of mobile payments. ISACA’s 2015 Mobile Payment Security Study found only 23 percent of IT and security professionals believe mobile payments will keep information safe—which, let’s face it, is not exactly a vote of confidence.
It bears asking, though, how that compares to the alternative. Meaning, are there risks to mobile payment scenarios? Sure. Show me a technology without some risk and I’ll show you a technology that’s completely valueless. But even if there is risk, what is the opportunity cost? What do we miss out on by waiting for some future scenario that is even more locked down? And how does the risk of mobile payments compare, for example, to the physical and e-commerce transactions that you perform already using your physical card?
Is a mobile payment scenario riskier than, for example, handing your credit card to a waiter at a restaurant? Is it more likely to bring about fraud than using a “knuckle-buster” in a taxicab? Is it more or less likely for the card number to be stolen when making a mobile payment versus entering the card number into the web form at a merchant? In most situations—and for most frequently encountered types of fraud—the traditional payment scenario is arguably significantly less risky than the mobile one.
For example, the mechanisms used to protect a point-of-sale mobile payment (e.g., tokenization and encryption) might have some advantages; likewise, a lost/stolen mobile phone probably provides better protection of the cardholder data (where usually enhanced authentication such as a fingerprint or facial recognition is required to make a payment) compared to a scenario like a lost/stolen wallet.
Holistic Analysis
In short, accounting for mobile payments from a holistic standpoint means understanding how the mobile payments themselves work, understanding what the risks associated with that usage are, and understanding how that usage might be applicable to the enterprise.
ISACA’s new white paper, Is Mobile the Winner in Payment Security?, tries to help practitioners do this. The paper outlines mobile payments from a practitioner point of view: going into potential risk areas, ways mobile payments can offset risks, and exploring business-enhancing value opportunities. Likewise, the document explores some possible controls that might bring about a value-add in light of mobile payments.
Ed Moyle, Director of Emerging Business and Technology, ISACA
It is unlikely there are many people left who have not heard of Pokémon Go. Maybe you are an active player, maybe your stock portfolio includes Nintendo shares, or maybe you have heard the warnings about criminal activity related to the game. For the uninitiated, Pokémon Go is a mobile app that uses a phone’s GPS and camera to create an augmented reality experience in which players traverse the physical world and capture animated creatures.
Niantic, Inc.—which actually began as a Google project before splitting off from the company last year—partnered with Nintendo to create the mobile app. Whether you are playing the game or not, one thing is for sure – this is a truly disruptive technology; one that came on the scene and infiltrated people’s lives in record time.
Just how pervasive is Pokémon Go? The app has drawn just under 21 million active daily users in the United States since its 7 July debut. In Germany the game was released on 13 July and rose to the top of the charts in just three hours. In less than two weeks Pokémon Go has attracted more daily active users than Twitter – an app that has been in existence for ten years.
From a practitioner perspective, concerns arise around such rapid and widespread adoption of an emerging technology. Organizations are often unable to accommodate such unprecedented interest—in this case, server issues plagued the game’s developers, particularly in the first few days of its release, when Niantic seemed unprepared for the rapid onslaught of users. High levels of usage may also increase exposure for security flaws, which may be exploited before an organization has an opportunity to correct them.
In the case of Pokémon Go, the software company has also come under fire for privacy concerns related to the game – while an update has since been released that corrects the error, an earlier version of the app granted full Google account access to Niantic when users chose that method of sign-in. When millions of users downloaded the app before the update was released, it is unlikely many of them were reading the fine print to understand the scope of access to their personal information they had handed over.
As technology professionals, we have an opportunity and an obligation to anticipate and prepare for what is next, even when we might not be quite sure what it is. While we may not all be developing the next viral app, we do all serve as advisors on technology in some capacity within our organizations. Technology is evolving at exponentially faster and faster rates, and it can seem daunting to keep pace. But even as advances are made, the old standards ring true – build privacy and security standards into technology from the beginning, optimize risk, and approach future technologies with a healthy sense of cautious optimism.
The most important aspect is when this comes into force, which is the 8th of August 2016. However, it is not immediately applicable: each member state then has a period in which to take the Directive and turn it into national legislation—that must be completed by the 10th of May 2018. It effectively then becomes live the following day.
As such, by the 11th of May 2018, you will need to be compliant if the Directive applies to your organisation; however, you should note that, although countries have until the 10th of May, they may choose to bring into force their own laws or regulations earlier, so now is the time to start engaging at your country levels to validate their planned timelines.
So what should be the next steps for any business’ cybersecurity team, now that the implementation timeline is defined and the Directive issued is final? Here are my suggestions:
1. Does it apply to your organisation? From research we are conducting with IDC, it is clear there is confusion. The Directive covers two distinct categories of entities:
Operators of Essential Services – a public or private entity that “provides a service which is essential for the maintenance of critical societal and economic activities; depends on network and information systems; and where an incident to the network and information systems of that service would have significant disruptive effects on its provision.”
Action 1: Although the Directive lists industry sectors and sub-sectors considered operators of essential services, each Nation has the requirement to identify which organisations in its territories will be included, so you will need to validate with your relevant national authority if your company is included.
Just because an industry sector is not listed as an “essential service” in the Directive, that does not mean it is not subject to security requirements in the EU. The Directive recognizes that some sectors already are subject to sector-specific EU requirements for security that are either in-line with or potentially higher than those defined in the Directive. (Among other things, the Directive requires covered organisations to take measures that have regard to the “state of the art”.)
Action 2: Validate if your industry sector has been identified as already being effectively exempt due to existing legislative or compliance requirements meeting/exceeding the Directive’s objectives.
Digital Service Providers (online marketplaces, online search engines, and cloud service providers) – these companies also have security and incident notification requirements, although they are less stringent than for essential service operators. Further, for digital service providers, requirements do not apply to “micro” or “small” enterprises as defined by EU law.
Action 3: Member states will not further define digital service providers, so the definition in the Directive is set. As such you should be able to determine immediately if it applies to you.
Action 4: The security and incident notification requirements for digital service providers will be developed by the European Commission. If you believe you are covered, there is the opportunity to influence the requirements. As a first step, there is currently a survey being conducted by ENISA on the incident reporting scope (responses are due at the end of July 2016).
2. What should you do next? The Directive states that both operators of essential services and digital service providers must take cybersecurity measures with regard to state of the art and also has requirements to notify relevant national authorities of cyber incidents.
Action 5: Now that the scope and timelines are defined, for those businesses that the Directive applies to, the next natural step is to start to complete the gap analysis.
How near to or far from the requirements are you?
Security and incident notification requirements:
Operators of Essential Services (from Article 14)
“Member States shall ensure that operators of essential services take appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems which they use in their operations. Having regard to the state of the art, those measures shall ensure a level of security of network and information systems appropriate to the risk posed.”
“Operators must notify, without undue delay, to the competent authority or CSIRT incidents having a significant impact on the continuity of the essential services they provide.”
Digital Service Providers (from Article 16)
“Member States shall ensure that providers “identify and take appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems which they use in the context of offering [online marketplace, online search engine, cloud computing services] within the Union.”
“Digital service providers must notify, without undue delay, to the competent authority or CSIRT any incident having a substantial impact on the provision of a service [search, online marketplaces, cloud] that they offer within the EU.”
What will be your strategy where you are required to become compliant?
Do you have budget assigned and the appropriate business support to achieve this?
How will you ensure you can validate and maintain the state of the art?
3. How do you leverage the resources that will be available to you? Each nation will be required to have a CSIRT, and the CSIRTs are encouraged to share among each other non-confidential information on cyber incidents and associated risks. These potentially will be able to provide great insight on what and where some of the key cyber risks are relevant to the businesses covered by the Directive. Likewise they should provide access to skilled resources that may be able to assist in the definition, testing and during incident response cycles.
Action 5: Do you know the CSIRT or competent national authority to which you may need to notify incidents? (Some CSIRTS/authorities may already exist; in other cases, member states will be establishing them.) How are you connected into them?
Action 6: Do you have an incident response strategy today. If not, how are you preparing for the requirement?
How are you leveraging the skills, knowledge and resources that may be able to help you define, validate or support you during an incident?
It may seem like 2018 is a long way out yet, but 2017 is effectively the year I would consider in which businesses need to achieve the Directive’s requirements. The remainder of 2018 should be kept to validate and test your businesses capabilities, be they achieving state of the art or testing your incident response and notification capabilities.
Being part of the infrastructure and digital services that are deemed at core to society can seem like a great responsibility; however, with that comes support from national entities and their trusted providers. For some organisations this may be welcome relief, as they need to increase their capabilities; for others, it may require very little change at all.
What is key for every business is to understand if the new Directive applies to them and then work with the national entities and their trusted providers to use the time allocated to understand the requirements, complete the gap analysis, and use the coming period so that their cybersecurity capabilities have the required regard for the state of the art in place by the May 2018 deadline.
