This article provides a review of the key trends and changes in the cyber crime landscape, recognizing that cyber criminals are now ruthless and rational criminal entrepreneurs supported by a vibrant black market in attack tools and techniques, and crime as a service model. The changing threat demands a new approach to cyber security which focuses on layered defences, detection and rapid response, agility in our security approaches, community sharing of threat intelligence, and a new partnership between government and industry around active defence.

Introduction

The term hacker brings with it images of teenagers hunched over keyboards in bedrooms taking on the might of government and major corporations. But does this image really represent the reality of the cyber crime threat, and does the word “hacker” get in the way of thinking about how we deal with the cyber threat?

The reality is often very different. Cyber crime has become a major industry with some estimates ([CSIS14]) suggesting that the impact on our global economy exceeds $400 billion a year. Gartner ([Gart16]) suggests that we spend over $94 billion to secure our systems against these cyber attacks.

Crime always follows money – and the money is now in cyberspace. According to the Bank for International Settlements ([BIS13]) our electronic markets transact over $5,000 billion of foreign exchange transactions in the space of just one day, while eMarketer ([eMar16]) suggests we spent over $1.7 trillion on e-retail in 2015 – a figure expected to double by 2019.

Unsurprisingly cyber criminals have become businessmen. Their business is exploiting access to computers for financial gain. In doing so they show a ruthless and rational entrepreneurial approach.

Think about the landscape from the perspective of the cyber criminal, rather than focusing on the technical attacks themselves. In this article, I provide a structured way of looking at the cyber crime landscape, picking up on key threat trends and drivers, breaking cyber crime down into three main categories of attack: commodity, tailored and high-end.

Next, I look at the implications for our approach to cyber security, considering how we need to change and adapt our defences to counter these emerging threats with an increased emphasis on detection and response, community action and in future industry/government partnerships around active defence.

Commodity Attacks – Playing the Numbers Game

The first category of attack is indiscriminate. It relies on the fact that a small percentage of the people and firms attacked will be compromised, but that can be turned into a steady income stream. It is a numbers game. The classic attacks in this category are ransomware and denial of service attacks for extortion purposes.

Ransomware has become the scourge of modern business. The attack methods themselves are basic but effective. Bulk phishing emails lead to a user clicking on a malicious attachment, their system becomes infected and the ransomware encrypts their storage preventing access to key files, the ransomware extorts a payment (often in bitcoins) from the victim.

The numbers are interesting. The University of Kent ([UKen16]) suggests that 4% of the internet users surveyed had been hit by ransomware. More interestingly 26% of people paid the ransom, and most (some 65%) got their files back as a result – perhaps honour amongst thieves. The average ransom itself is small – often a single bitcoin – typically around $670 according to Symantec ([Syma16]). For those of you who like playing with statistics, try this UK example:

UK population – 65 million ([ONS16])
4% have been hit by ransomware – 2.6 million
26% of people paid up – 0.68 million
$650 average ransom – circa $440 million income

Not too bad… of course the figures are wrong, but they are in the right ballpark. They also omit the impact on businesses. Trend Micro ([Tren16]) provides a view on ransomware attacking UK businesses which helps build up the picture. 44% of firms surveyed were attacked by ransomware in the last 24 months, with a surprising 65% paying the ransom.

Ransomware has been with us for many years, but there has been a major growth in the range of variety of ransomware since Autumn 2015 ([CERT16]). This reflects a change in the nature of organised crime, with a shift from individual organised crime groups developing their own bespoke ransomware tools to the purchase of ransomware in the form of Crime-as-a-Service (CAAS).

C-2016-3-Ferbrache-01

Figure 1. Crime-as-a-Service.

Denial of Service

Ransomware is a key mechanism for extortion, but not the only mechanism. Distributed denial of service attacks which overload web sites and internet facing business portals with malicious traffic are now commonplace. Historically, attacks have been carried out by networks of compromised computers (botnets) which generate large amounts of internet traffic which swamp and overload target websites.

Law enforcement has been increasingly effective in disrupting the operation of botnets working closely with security firms to understand how they operate, the weaknesses in their infrastructure, and how they might be shut down. In particular the Europol Cybercrime Centre (EC3) has played a vital role in co-ordinating action to disrupt such botnets. The takedown of the RAMNIT botnet in February 2015 ([Euro15]) involved Europol working with investigators in Germany, Italy, Netherlands and the United Kingdom – as well as industry partners from Microsoft, Symantec and AnubisNetworks – to disrupt a botnet of over 3.2 million computers.

For their part, the criminals have moved to improve the security of their botnets using encryption to protect their communications, as well as looking for unconventional systems which can be built into new botnets. A recent example reportedly ([OVH16]) used over 145,000 compromised cameras and digital video recorders to create the world’s largest DDOS attack – 1 Tbps. Of course, criminals have also been an early adopter of cloud computing to provide the computing power for their attacks.

Denial of service can now be purchased as Crime-as-a-Service, with it typically costing between $5-$10 per hour to launch an attack against a website. This has resulted in a major increase in short duration relatively unsophisticated DDOS attacks against a wide variety of targets, often linked to attempts to extort small sums (a few bitcoins – some $600) from the victim in return for ceasing the attack.

Tailored Attacks – Online Confidence Tricks

Commodity attacks represent just one element of the threat to organisations and businesses, representing the inevitable background noise of the internet. There are of course examples of organised crime groups investing more time and effort to target firms, their employees and executives.

Business Email Compromises

The single biggest pattern of fraud at the moment is the business email compromise (BEC) fraud or its close relative the CEO fraud. The FBI ([FBI16]) reports over $3.1 billion of such frauds, but most worryingly since January 2015 they have seen a 1,300% increase in levels of reporting as criminals scale up their operations.

The average amount stolen in these frauds is some $140,000. Two recent multi-million pound cases include Action Fraud ([Acti16]) reporting a global healthcare provider who transferred $23 million to an Asia-Pacific bank account, and Reuters ([Reut16a]) reporting a Romanian wire and cable manufacturer who transferred $44 million to a Czech bank account.

These attacks blend technical attacks with social engineering to carry off what is effectively a sophisticated on-line confidence trick. The target of these frauds are normally financial controllers, corporate treasuries, payment clerks and accounting departments. The aim is simply to trick them into authorising a large financial payment to a bank account of the fraudsters choosing.

The attacks start with careful research into the firm, often undertaken through social media, to identify who are the key individuals who could authorise payments and just what story would work best. This is then followed by meticulously crafted phishing emails which look extremely realistic, using the correct corporate logos, the right email address formats, the typical language used within the company or sector, and even a previous trail of fake correspondence from senior executives providing the context to the request. These phishing emails are often linked to telephone calls and SMS text messages, building the story up over time, establishing confidence, and then cashing out.

Attackers will set up fake email accounts using email ids based on the names of senior executives, or even hack the mail system of lawyers and accountants to send emails to their target.

Box 1. BEC Fraud Tactics.

Business Email Compromise Fraud Tactics

Supplier Change of Banking Details

A fraudulent request is made to change the banking details of a long standing supplier. The email will be well crafted using the correct logos, it may also come from an email account which closely resembles the supplier’s legitimate email address.

Wire Transfer

An email is sent purporting to come from a C level executive. The email may come from a fake email account with an address which looks credible, or may even come from their own personal email account if it can be hacked. The email asks for an urgent wire transfer of funds to an overseas bank for a sensitive and confidential project.

Fake Invoice

An employee has their personal e-mail account hacked, ideally an account they also use for work purposes. Fake invoices are then sent from their email account to suppliers given the account details of the fraudsters account.

Lawyer Impersonation

The fraudster purports to be a lawyer or representative of a legal firm handling confidential and/or time sensitive business on behalf of the firm. The victim is pressurised into transferring funds urgently.

The frauds are backed up by large scale social engineering using sophisticated call centre networks. As an example, in December 2015 Interpol ([Inte15]) co-ordinated the arrest of over 500 such call centre workers across 15 call centres. These arrests included: 245 Chinese and Taiwanese nationals in Indonesia; 168 Chinese nationals in Cambodia; and further arrests in China, Hong Kong, Korea, Thailand and Vietnam which included Korean, Nigerian, Filipino and Russian nationals. Cyber crime has become truly international in scale and reach.

Banking Trojans

While BEC frauds grow, other traditional forms of cyber crime may be becoming less so, forcing cyber criminals to evolve and adapt. Banking Trojans have been with us for over a decade. Criminals use phishing emails (or compromised web sites) as the means of tricking the user into downloading malware onto their computer. Once installed, the malware will modify the user’s web browser to interpose itself between the user and their e-banking session. This allows the attacker to modify banking transactions, submit their own payment requests, and ensure that the user does not spot those fraudulent transactions when viewing their balances or statements.

Banks responded to these attacks in a variety of ways, including encouraging customers to use security software, raising awareness, and of course introducing additional authentication checks such as two factor authentication (for example, an SMS message sent to your mobile with a secret code to authorise the transaction). Together with targeted law enforcement action against the developers and operators of these bank Trojans, this has resulted in a major drop in fraud levels to just over 1 bps (0.01%) of transaction volumes.

Organised crime groups are attempting to innovate to overcome these security measures. For example, there has been a major increase in SIM Swap frauds where the criminal attempts to trick mobile network operators into transferring a mobile phone number to a new device (owned by the criminal) by persuading them that the original phone has been stolen. Countering these attacks demands closer collaboration between financial firms and mobile network operators, as well ensuring that the risk scoring undertaken by banks when approving on-line transactions takes into account the device being used.

Card Not Present

Cyber criminals are always interested in payment card details and a vibrant black market exists to sell on such information. The traditional approach of skimming card details at the point of sale or when used in ATM machines continues, with such card details being used to create fake cards for use in countries where the adoption of chip and pin (EMV) card security is less advanced. Over time the opportunities to use such cards will decline, particularly following the decision by US card scheme operators to shift liability to merchants if they do not implement such technology.

So the patterns of attacks change once more, with organised crime groups focussing on Card Not Present frauds where the e-retailer is able to initiate transactions without the cardholder being physically present. According to Financial Fraud Action ([FFA16]) these frauds represented some 70% of payment card frauds in the UK in 2015. E-retailers are increasingly in the sights of organised crime as the digital economy grows.

Data Theft

The final category of tailored attacks focuses on data theft. For the most part the target is personal information which can be used to undertake identity theft and fraud. Once again there is a vibrant market in personal information on the dark web, with Fullz (a complete profile for a person including addresses, work details, date of birth, social security numbers, credit card information etc.) selling for up to $15-$65 per person according to Dell Secure Works ([Dell16]).

Bulk data breaches are now endemic, with Breach Level Index ([BLI16]) reporting over 4.8 billion records compromised since 2013. These numbers are likely to be swelled by a recent Yahoo report ([Yaho16]) of over 500 million sets of Yahoo account details being breached allegedly by a state sponsored attacker. Encrypted passwords can be cracked and plaintext recovered (particularly when compromised security questions provide helpful hints). People re-use passwords across multiple systems providing an in for attackers.

High End Attacks – Advanced and Persistent

The most worrying of the attacks, sharing many of the characteristics of a cyber espionage operation and taking place over weeks and months. The attackers start with tailored phishing emails or the use of compromised web sites to distribute malware to their target. Once they have succeeded in infecting an initial system their approach becomes very different. They aim to establish remote control of the infected computer and use that computer as a launch pad to infect other target systems, while keeping a close eye on what the users are doing on those computers. Their monitoring activities may even include capturing copies of the user’s screen and every mouse movement or key stroke on that system. They spend time understanding how the system works, how the fraud controls in the organisation work (including just who needs to authorise payments), and how they might defeat those controls. Then they cash out.

Unlimited Cash Out

There have been a number of examples of banks or payment processors being compromised in order to steal credit card information and then remove the withdrawal limits on those cards prior to them being used overseas. A recent example in International Business Times ([IBT16]) from May this year involved stolen South African bank data being used to create cloned cards which were used to withdraw over 1.5 billion Yen from 14,000 convenience store cash machines across Japan within a 3 hour period. According to the Federal Financial Institutions Examination Council ([FFIE14]) a similar operation in 2014 netted the attackers $40 million using just 12 debit card accounts.

Bank System Compromise

In late 2013 and 2014 an unusual series of attacks occurred against Russian banks. Kaspersky ([Kasp15]) reports that over 50 banks were targeted in a sophisticated operation which came to be known as Carbanak. The attackers used phishing emails which appeared to be from the Russian central bank to gain initial access to the target banks, they then spent two to three months in the systems of each bank looking for an opportunity to cash out. Their cash out strategies were creative ranging from simple inter-bank transfers; to the use of electronic payment channels such as web money, Yandex and QIWI; and even one case of manipulation of bank ATMs to change the denomination of notes in the ATM cash dispenser.

This year we have seen a high profile attack against the Bank of Bangladesh which reportedly ([Reut16b]) attempted $951 million of fraudulent transfers via their SWIFT payment system gateway to various overseas bank accounts, with some $81 million being successfully transferred to bank accounts in the Philippines prior to money laundering through Filipino casinos. Further attacks have also reportedly ([Reut16c]) been attempted against other banks including the theft of some $10 million from a Ukrainian bank.

These attacks raise concerns about the inter-connectedness of the global financial system. The security of that system is dependent on the security of the component banks, with the associated risk that a single weak link will compromise the integrity of the system. SWIFT are now acting to strengthen payment security standards across banks globally, with the Bank of International Settlements expected to follow suit.

Secondary Market Manipulation

A final form of organised crime is one where the victim is less clear. Criminal groups have begun to focus on market sensitive information as a way of making money. In one high profile attack, three major newswire services were reportedly ([USAO15]) broken into, with criminals stealing over 150,000 corporate news releases in the 24 hour window before the newswire released the news to the market. The news releases were then farmed out to a network of traders who could selectively front run the stocks in the market to profit from the price changes which followed the news being made public. The group was alleged to have made over $100 million in profits.

Organised crime is becoming increasingly creative in its approach to money making – and has built a sophisticated cyber underworld.

Figure 2. Cyber Underworld. [Click on the image for a larger image]

What Does This Mean for Cyber Security?

Get the Basics Right

The basics of security matter – not just for organisations but also for their key suppliers. Commodity attacks impact every firm, if not now, then tomorrow. Firewalls, anti-virus protection, email security and backup policies matter. For firms with an on-line presence, denial of service protection has now become one of those basics. Without these basics organisations are vulnerable to straightforward ransomware attacks, as well as being exposed to the most incompetent of organised crime groups leveraging Crime-as-a-Service offerings.

Increasingly firms will be expected to demonstrate that these basics are in place, whether by corporate customers demanding assurances of security from their suppliers, by insurers who refuse to pay out on cyber insurance policies unless reasonable care is being taken, or by regulators who are likely to impose growing sanctions for firms who are perceived to have been negligent in their security or data protection.

The single most important cyber security basic is not a technical countermeasure, it is education and awareness. Employees are often the weakest link in security, sometimes through carelessness, occasionally deliberate action, frequently through ignorance. Awareness is not just about annual security training, it is about making sure employees are aware of current threats and patterns of criminality, as well as being clear on how to respond if they are targeted by malware or suspicious activity. But the reality remains – people will always be the weakest link in security, and we as security professionals do not do enough to make security straightforward and unobtrusive.

Building on the Basics

Going beyond the basics, means establishing a robust information security management system which embeds security into corporate systems. At the heart of this is effective leadership and governance – setting out clear ownership, accountability and sponsorship for cyber security at board level, with a well articulated and communicated policy framework.

Cyber security is not a technical issue, it is a business issue which has become increasingly important in our digital world. Success comes when cyber security is embedded into business strategy, and the organisation focuses on the defence of its key assets against a variety of threats including, of course, cyber crime. An organisation’s cyber security stance must also be informed by credible intelligence about a rapidly changing threat, as well as keeping track of the increasingly interventionist regulatory approach adopted by governments worldwide that are frustrated at ongoing cyber incidents.

Cyber security must be embedded into the business processes of the organisation, including: risk management, project management and compliance monitoring. Most critical of all, cyber security should be considered in vendor and supplier management recognising that third parties can create a route for attacks on organisations.

Any cyber security programme must also take a holistic approach which considers not just security technologies, but most critically the people dimension of leadership, education and awareness, along with the process changes to embed cyber security in the organisation. But is this enough, or even sometimes too much?

Figure 3. Building out an information security capability. [Click on the image for a larger image]

Agility

Conventional security wisdom suggests firms should establish a risk based approach to security which reflects the threats which face the firm and the value of the assets they are trying to protect. This approach is valid, but if taken to extremes can translate into a highly structured approach to security which builds governance structures, strategies, policies, reporting and compliance regimes. While important, these structures can become bureaucracies and prove inflexible.

Organised cyber crime is innovative, creative and flexible. The threat evolves with criminal groups changing tactics, tools and targets. This places a premium on our ability to adapt to that threat, including:

Threat and Vulnerability Management – keeping track of vulnerabilities across your IT estate, prioritizing which vulnerabilities need to addressed and being able to rapidly deploy security upgrades to counter current threats.
Security Operations – monitoring unusual and anomalous behaviour or security events within your organisation, setting those events in the context of the business operations, and being ready to respond quickly and effectively to malicious activity.
Cyber Intelligence – having access to current intelligence on the pattern of cyber attacks against your sector, or even better tailored intelligence matched to your business footprint.
Red Teaming – a regular programme of testing your security defences from the perspective of an attacker – not just technical testing but intelligence collection and social engineering of your company.

The “Cyber operations” teams undertaking these roles within an organisation need to be given the licence to rapidly respond to new and emerging threats, and with appropriate supervision they need to be allowed to work across the whole organisation with freedom to be innovative in the approaches they take.

Cyber Resilience

Cyber operations are important, but are not the ultimate answer to cyber attacks. This lies in developing a cyber resilient organisation. This phrase, much loved by US and UK regulators, hints at a way of thinking about how an organisation would adapt, respond and recover from a cyber attack. It includes:

Cyber Scenarios and Exercises – developing credible cyber security scenarios and exercising them at senior level to develop the “muscle memory” needed to respond in an emergency and to test that response.
Embedding cyber thinking into disaster recovery – making sure that business continuity and disaster recovery plans include the potential for cyber attack not just physical threats to the organisation – this can be a very different way of thinking about points of failure.
Resilient by design – building resilience into the design of corporate information systems and business processes – including how fall-back and recovery arrangements would work whether manual or automated.
Cyber insurance – understanding the role of cyber insurance in positioning the business to deal with more extreme cyber scenarios, including access to specialist support in the event of a major incident.

Community Response

No organisation is an island. Organised crime attacks large areas of our economy. Each organisation will see a small part of the activities of the criminals. All of this underlines the need for firms to work together to counter the cyber threat. Historically this has happened in sectors which were most commonly attacked, notably the financial sector (through organisations such as the Financial Services – Information Sharing and Analysis Centre, FS-ISAC) and defence sectors (through various government sponsored schemes). A great example of cross-sector sharing and collaboration is the International Information Integrity Institute (I-4), which brings together large global organisations across a number of sectors: Banking, Telecoms, Insurance, Oil & Gas, Pharmaceuticals, Manufacturing and Tech, for exactly that purpose. It recognises that no one organisation nor one sector can operate in isolation as attacks will often be connected, starting in another sector before traversing to another. Working with other sectors brings new perspectives and an extended peer group for challenge and support.

As the threat develops and grows there is a need to build broader communities linking the financial sector which processes the fraudulent payments to the organisations which unknowingly initiated those payments (for example e-retail). The telecommunications sector also brings unique insights by being able to tie internet addresses to user devices and geographic locations, as well as being a key player in preventing SIM swap frauds.

The pace at which attacks flux and change also demands automation of the exchange of threat intelligence and incident patterns across the community.

Active Cyber Defence

The last component is active cyber defence. The UK government recently announced ([Reut16d]) their intention to establish a national defence capability to actively disrupt cyber attacks against UK firms and citizens. This is expected to include collaboration between government and telecommunication operators to block phishing emails, known bad websites and compromised computers; as well as disrupting the communications between the criminals and the malware they have successfully deployed. We can also expect continuing collaboration between law enforcement and technology firms to takedown botnets and other criminal infrastructure.

A layered model of cyber defence is emerging – based on organisational, infrastructure and national defences – working together to take the offensive against a transnational and sophisticated cyber crime threat.

Conclusion

The cyber crime landscape is changing driven by ruthless rational entrepreneurs backed by a highly effective black market economy in Crime-as-a-Service and stolen personal data. This demands that we look beyond conventional security approaches to focus on creating a security response which is agile and flexible, while focusing on the key assets the organisation wishes to protect and their potential exploitation by criminals. A community response is vital, recognizing that we all face aspects of the threat, and all of us have key pieces in the jigsaw of cyber intelligence. But we also see the start of a new relationship between government and industry, and perhaps a very different approach to active cyber defence and the disruption of organised criminality.

References

[Acti16] Action Fraud, Action fraud warning after serious increase in CEO fraud, February 2016.

[BIS13] Bank for International Settlements, Triennial Central Bank Survey, September 2013.

[BLI16] Breach Level Index, Data breach statistics as at 25^th September 2016.

[CERT16] CERT-UK, Is ransomware still a threat?, May 2016.

[CSIS14] Centre for Strategic and International Studies, Net Losses: Estimating the global cost of cyber crime, June 2014.

[Dell16] Dell Secure Works, Underground hackers market, Annual Report, April 2016.

[Euro15] Europol, Botnet taken down through international law enforcement co-operation, February 2015.

[eMar16] eMarketer, Worldwide Retail eCommerce Sales, 2016.

[FBI16] Federal Bureau of Investigation, Business email compromises, Public Service Announcement, I-061416-PSA, June 2016.

[FFA16] Financial Fraud Action, Fraud the facts 2016, May 2016.

[FFIE14] Federal Financial Institutions Examination Council, Cyber attacks on financial institutions’ ATM and card authorization systems, April 2014.

[Gart16] Gartner, Information Security, Worldwide Forecast, 2014-2020, 2Q16 Update.

[IBT16] International Business Times, Fraudsters steal $13 million from over 1,400 ATM, May 2016.

[Inte15] Interpol, More than 500 arrested in INTERPOL operation targeting phone and email scams, December 2015.

[Kasp15] Kaspersky, Carbanak APT, the great bank robbery, February 2015.

[ONS16] Office of National Statistics, Overview of the UK population, February 2016.

[OVH16] OVH, https://twitter.com/olesovhcom/status/778830571677978624, September 2016.

[Reut16a] Reuters, Germany’s Leoni defrauded of 40 million Euros, August 2016.

[Reut16b], Reuters, Bangladesh Bank official’s computer was hacked to carry out $81m heist, May 2016.

[Reut16c], Reuters, Ukraine central bank flagged cyber attack in April, June 2016.

[Reut16d], Reuters, GCHQ looks at creating national internet firewall, September 2016.

[Syma16] Symantec, Special Report: Ransomware and Businesses, 2016.

[Tren16] Trend Micro, UK businesses bullish about ransomware, September 2016.

[UKen16] University of Kent, Cyber Security Survey, September 2016.

[USAO15] US Attorney’s Office, Nine people charged in largest known computer hacking and securities fraud scheme, August 2015.

[Yaho16] Yahoo, An important message about Yahoo user security, https://yahoo.tumblr.com/post/150781911849/an-important-message-about-yahoo-user-security, September 2016.

Cyber in the Boardroom

An organization’s board does not only have a key responsibility for securing information assets, but they are in the best position to effectively allocate and steer resources towards cyber security. We review a standard model for board responsibility and we describe our Cyber in the Boardroom methodology that addresses each facet of the model. Finally, we present research on the current state of reporting cyber resilience aspects in annual reports, one of the responsibilities of the board in our methodology.

Introduction

As the number, impact and media coverage of cyber security incidents have grown in recent years, investors, governments, and global regulators are increasingly challenging board members to demonstrate diligence in the area of cyber security. Regulators expect personal and sensitive information to be protected and systems to be resilient to both accidents and deliberate attacks; value chain partners expect a trustworthy and transparent approach to risks; and customers expect that services are available and that their data is protected when stored or processed by organizations.

Boards need to respond to the above pressures, but many board members have a poor understanding of cyber risk and are unsure how best to address these issues. Other members believe responsibility for cyber security rests with the IT or security department. Our work with organizations suggests that not only does the board have a key responsibility for securing information assets, but that they are in the best position to effectively allocate and steer resources towards cyber security. And improving cyber security effectiveness is needed, as indicated by a 2016 KPMG survey of CEOs regarding their organization’s preparedness for cyber events (Figure 1).

C-2016-3-Diemont-01

Figure 1. CEO survey on company preparedness for cyber events.

In this article we review a standard model for board responsibility and then describe our Cyber in the Boardroom methodology that addresses each facet of the model. Finally, we present research on the current state of reporting cyber resilience aspects in annual reports, one of the responsibilities of the board in our methodology.

A Model for Board Responsibilities

To understand why corporate boards need to understand cyber security and how their needs are served by our methodology, we first need to create a model for board responsibilities. There are several such models but for this paper we focus on the one created by Bob Tricker, an influential researcher in the field of corporate governance. This model, created in 1994, is displayed in Figure 2.

C-2016-3-Diemont-02

Figure 2. Bob Tricker’s model for corporate governance.

As the figure shows, boards have duties to both internal and external parties. In addition, their activities are sometimes past/present focused and sometimes future focused. Let us take a closer look at each quadrant, starting with Strategy Formation and proceeding clockwise.

Strategy defines how the expectations of the external stakeholders will be met, and we noted in the introduction that several key stakeholders (investors, regulators, business partners and governments) are raising their expectations of the board with regard to cyber security. Furthermore, many business strategies are based on IT innovations, so a focus on cyber security should increase with equal measure.

Strategy needs to be supported by a set of policies that translate the high-level, long-term objectives of strategy into actionable plans. Awareness programs must also be established to steer the corporate culture in specific directions. Together, policies and awareness programs reduce risks and change employee behavior. Both are critical in the domain of cyber security.

Once implemented, policies and awareness programs need to be assessed to determine their effectiveness. This is the monitoring category. Key performance indicators (KPIs), key risk indicators (KRIs) and key goal indicators (KGIs) help the board understand trends in management effectiveness at delivering desired results. Good indicators show the benefits of investments and could indicate areas where more resources need to be allocated or changes need to be made.

A final responsibility of the board is being accountable to external parties through independent audits and published reports. These reports discuss not only financial data but also major risks and trends while the audit findings demonstrate compliance to regulatory standards (e.g. Payment Card Industry-Data Security Standard). A case study will be discussed later in this article.

How does cyber security fit into this governance model? Very easily. Our “Cyber in the Boardroom” methodology addresses each board responsibility in turn, incorporating the top-down approach on the performance side and the bottom-up approach on the conformance side. We now describe this approach in more detail.

A Methodology for Cyber in the Boardroom

The Cyber in the Boardroom methodology (see Figure 3) helps board members answer their most common questions: how to gain insight into their current risk posture, how to steer and assess the effectiveness of their cyber security program and how to develop key risk indicators. The steps are as follows.

C-2016-3-Diemont-03

Figure 3. Cyber in the Boardroom methodology.

1. Assessing the Organization’s Current Cyber Risk Posture

An organization cannot move forward intelligently without knowing where it stands. Thus a first step in strategy formation is to gain insight into its current risk posture, which can be done by assessing governance models, human factors, information risk management, business continuity, crisis management, operations and technology, and legal and compliance profiles. KPMG’s Cyber Maturity Assessment (CMA) methodology is a strong tool to assess these domains because it automatically provides benchmarking against industry peers using KPMG, NIST and/or ISO maturity scores.

2. Perform an Information Risk Assessment

The next two steps cover the information risk management (IRM) process that is described in greater detail in two previous articles (see [Herm13] and [Hars14]). In summary, identifying critical business processes and assets is a key step in effectively allocating limited resources to have the greatest business impact. The involvement of board members and senior business leaders in this process is necessary to ensure the highest business priorities are covered. Otherwise, lower management may exaggerate the importance of their division or service lines, which can lead to sub-optimal investments.

Risks are composed of event likelihoods and impact. In the cyber domain, likelihoods are often calculated by considering how threats can exploit specific vulnerabilities. Therefore, business must be aware of which threats will have the biggest impact if they materialize and which vulnerabilities are the most critical. The end result of this process is a top-level overview of the major risks from an information management perspective.

3. Select and Steer Your Defense

Once these top risks have been identified, business leaders must consider their appetite for risk and determine whether specific risks will be transferred, mitigated, avoided or accepted. The establishment of a cyber security steering committee, which consists of both business and support functions, e.g. IT Risk, Legal, Compliance, Internal Audit, can improve the execution and monitoring of these decisions. A complete overview of residual risks using a risk register is also recommended to ensure the business is not holding risks in excess of its defined risk appetite.

4. Develop Policies and Security Awareness Programs

Creating a cyber risk culture can pay large dividends over time and vastly improve the security of any organization. Two important ingredients to affect a change in culture and procedures are: policies and security awareness programs. Policies provide concrete directions on how to implement the risk strategies selected in the first three steps. They should be further refined into detailed procedures and guidelines for technical domains to ensure consistent application across regions and to improve resilience despite employee turnover. Security awareness programs attempt to change human behavior and should cover all internal parties, from board members to entry level joiners. Humans are often the weakest link in cyber or information security so creating awareness among employees regarding the value of the information assets and best practices to prevent or report security incidents can act as an insurance policy for the large investments made in customer procurement, IT assets and branding. Changing behavior is difficult and the threat landscape is ever changing so awareness programs must be regularly administered and frequently updated.

5. Enhance Monitoring

After establishing or approving the performance actions in the first four steps, the board must maintain insight and report to external stakeholders on the effectiveness of their information risk management. The selection of KPIs, KRIs and KGIs with the greatest impact is critical to attain informed oversight and to assess where additional resources need to be directed. Downward trending indicators may also suggest that the threat landscape has changed or security assets have become outdated. The reporting of threats, risks and compliance is not only a legal requirement but also provides input to the next iteration of strategy formation. We explore the current state of cyber and information security within annual reports in the last section of this article.

A well-designed cyber dashboard is key to providing a periodic, comprehensive and integrated picture that will address board questions or concerns. It should not only provide insight into the organization’s current state of cyber resiliency but should also provide feedback on the effectiveness of security management and highlight the value of past investments. Although similar in concept, actual security dashboards are highly customized. Our team has created a methodology for dashboard development (Figure 4) that accounts for the target organization’s specific information needs, its data sources and its available platforms. These requirements and capabilities are gathered via interviews and workshops with key stakeholders during the initial design phase. It is during this discovery stage that we encourage organizations to adopt a comprehensive view on cyber security and to consider KPIs, KRIs and KGIs that address non-technical security domains in addition to technical ones.

Figure 4. Cyber dashboard development methodology. [Click on the image for a larger image]

Our general framework for dashboard categories is presented in Figure 5. Let us look at example visuals for each element.

Figure 5. Cyber dashboard domains. [Click on the image for a larger image]

Threats

Threats represent potential forces that can negatively impact business operations if they materialize. We consider both external sources (e.g. hackers hired by organized crime) and internal sources (e.g. lack of a secure coding standard for application development) for threats. Figure 6 shows how threats may be presented on a “threat radar”. The organization’s ability to manage the threat is plotted against the threat’s potential impact. In addition to the radar, the dashboard may also indicate the trend in the threat level since the previous reporting period and what projects, systems and/or actions the organization is using or taking to address the threats.

Figure 6. Threat radar. [Click on the image for a larger image]

Risks

Risks combine high potential threats to known vulnerabilities within the organization and are specific enough for decisions to be made whether to accept, mitigate, transfer or avoid them. Risk maps are a common way to display risks and an example is shown in Figure 7. Here risks are plotted depending on their likelihood and impact. Colors are often used to highlight criticality and may define required actions (e.g. red actions must be mitigated or otherwise the business must sign a formal risk acceptance document). These colors are frequently aligned with defined risk acceptance statements or tolerances. Like threats, there is usually an accompanying table that shows the changes to the risk since the last period, the risk owner (person to act) and the next steps.

Figure 7. Risk map. [Click on the image for a larger image]

Compliance

Compliance informs the board about how well the organization is adhering to defined thresholds and controls. Security-related audit findings can be displayed but other representations, such as highlighting the organization’s capability to detect, protect, respond and recover, can also be developed. Figure 8 shows just one example that highlights not only the number of findings but also the ability of organizations to resolve the findings within specified timelines.

Figure 8. Security related audit findings and remediation. [Click on the image for a larger image]

Incidents

Security incidents highlight the major security events during the last reporting period. These incidents can provide insight into risks and threats and the security function’s ability to respond. Detection and response are critical components of the security process because achieving 100% prevention is nearly impossible. Dashboards usually use tables to review incidents and include information on data sensitivity, business impact and lessons learned. In addition, information on time to detect and time to resolve the incidents provide information on organizations resiliency.

Awareness and Culture

People are often the weakest link in a security system and can negate heavy investment in security hardware and software products. Therefore, investments in security awareness can represent a force multiplier in an organizations security plan. Speed dials (Figure 9) showing the coverage of security awareness programs, the percentage of staff who have failed to complete training within timelines and surveys/tests of security knowledge are frequent dashboard elements.

C-2016-3-Diemont-09

Figure 9. Speed dials related to security awareness.

Projects

Projects highlight ongoing efforts to improve security and address security issues identified on the other dashboard categories. Tables of security-related projects indicate the project owner, whether it is on schedule and risks to the projects, among other possible attributes.

Once we have a clear understanding of an organization’s requirements and capabilities, we can begin selecting relevant key performance/risk indicators and start developing a dashboard prototype. This prototype is then presented for feedback and the development process progresses in an agile fashion with multiple rounds of feedback and improvement until an acceptable model is put into production.

The KPMG Approach Addressing Board Responsibilities

Let us revisit the model for board responsibility that we presented at the beginning (Bob Tricker’s model in Figure 2) and see how KPMG’s Cyber in the Boardroom approach helps boards meet these responsibilities regarding cyber security. We plotted the components of our approach in relation to the model in Figure 10.

C-2016-3-Diemont-10

Figure 10. Bob Tricker model incorporating KPMG’s Cyber in the Boardroom approach.

As one can see, the first four steps help the board with performance activities while the cyber security dashboard assists with conformance duties. Determining the current risk posture and conducting a full information risk assessment are important aspects of cyber security strategy formation. Selecting and steering defensive measures, spans both strategy and policies – risk actions are more strategy activities while the duties of the information security steering committee relate to the policy side. The next step is directly addressing policies and awareness training, an inward looking performance activity of the board. Finally, a dashboard informs the board of all conformance related topics, both inward and outward looking.

We note that while the dashboard informs the board about risks and compliance issues, the board itself must update external stakeholders regarding these topics. One requirement for doing this is through annual financial reports. We now present our research on the extent to which cyber security is addressed in these reports, focusing on the AEX and Midcap-listed organizations (top 50 listed organizations in the Netherlands by capitalization weight).

Understanding the Current State of Affairs

An annual survey by KPMG on the reporting of cyber security risks in the annual reports of AEX and Midcap-listed organizations shows that the reporting of these risks is currently inadequate. Although more than 83% of annual reports mention cyber security, further investigation reveals that only 66% do so with any degree of depth in terms of threats, risks or measures taken.

In some sectors we see a strong focus on cyber security risks in annual reports, such as in the financial sector where the Dutch Central Bank, and in turn also the European Central Bank, have expressed strong expectations in this regard. The paragraph “A Sector View” provides more information about the differences per sector.

Too often “cyber” is left to individual departments within organizations (almost always the IT department), and often even the CIO can no longer “see the wood for the trees”. This results in a diffuse approach and a lack of focus on the ultimate risk to the organization. We see this in the reporting to shareholders in the annual report as discussed previously. And while the topic is increasingly addressed in annual reports, there has been little progress in terms of the depth to which the topic is discussed; in fact, there has been a slight regression in this regard.

Let us look at other research insights. More than in previous years, responsibility for managing the risks of cyber security is laid at the door of the executive board. Figure 11 shows the number of annual reports which discussed the subject of cyber security and to what depth, as well as the percentage of annual reports that deemed the risk of cyber security to be a matter for the executive board.

Figure 11. Percentage of annual reports discussing cyber security. [Click on the image for a larger image]

A Sector View

Sectors differ in their dependence on IT, as can be seen in Figure 12. Organizations in diverse sectors also assign different values to the “crown jewels” of the organization. It is therefore not surprising to see a big difference between the number of organizations within a sector addressing cyber security in their annual reports, how in-depth the coverage is and whether the issue is regarded as a responsibility of the board. For some sectors it could be true that more important risks exist than cyber security. However, some generic cyber security risks apply to every company, such as: integrity of financial data; continuity of the organization based on the IT environment; confidentiality of customer/employee private data. Addressing these cyber security risks should be a minimum for annual reports.

Figure 12. Sector overview of annual reports discussing cyber security. [Click on the image for a larger image]

It is plain to see that organizations in the technology and financial services industry have a strong focus on this topic and regard it as a responsibility of the executive board. A sector like real estate, on the other hand, is clearly less concerned about the subject. Opportunities for improvement are readily present.

Summary

We believe cyber security is an important topic at the board level. This can be understood by observing the increasing cyber security expectations external stakeholder are placing on the board and the board’s responsibilities in meeting those expectations. Our “Cyber in the Boardroom” approach addresses these responsibilities by assessing an organization’s current risk posture, identifying its crown jewels, developing a strategy and directing internal stakeholders on how to achieve strategic goals with awareness education and policies. The final element, dashboards and reporting, measures management effectiveness in achieving stated objectives and provides information for reports back to external stakeholders.

Boards are experienced at identifying and addressing risks so they are more than capable of addressing cyber security risk as well. And to some extent they do. Our research demonstrates that boards are already reporting on cyber risks in annual reports but they can improve the depth of their analysis. We believe doing so will better inform external stakeholders and further improve the cyber risk management process, creating a safer environment to conduct business.

References

[Hars14] A. van der Harst, J. Hermans and P. de Meijer, Realizing the 2020 Vision of Information Risk Management, Compact 2014/1.

[Herm13] J. Hermans, A. van der Harst, P. de Meijer and S. Verkaart, The 2020 Vision of Information Risk Management, Compact 2013/1.

The Return to the Customer: Three Strategic Choices of Privacy Management

With the recent changes in rules and regulations, and academics stating that privacy is confusing, it is not a surprise that implementing effective privacy management is not an easy activity in practice. For organizations, there is no one-size-fits-all or best practice approach. This is shown by the many frameworks available and many questions posed by organizations. Organizations have given us insights into their privacy management, and revealed an interesting trend: privacy becomes about the individual again.

Introduction

Ever wondered what the fuzz surrounding privacy is all about? It is all a result of rapid technological developments and changing privacy regulations. Rapid technological developments have provided us the opportunity to collect, store and distribute information via all sorts of digital technologies. As a result, a lot of personal information has been made digitally available: your taxes, your medical history and your expenses, to name but a few (see Figure 1). You can store your data in the cloud and access it via your phone, regardless of your geographic location. Organizations have embraced this development to offer new services such as cloud storage, block chains and virtual reality. Not only to the end user, but also to their own employees, in terms of an online environment to consult their paycheck and change the information of their place of residence, for example.

But these opportunities come with the risk of violating the fundamental rights of the individual when systems are breached and personal information falls into the wrong hands. Governments try to protect these fundamental rights of the individual by tightening the privacy rules and regulations. With the frequent changes of the last years, it is not a surprise that implementing effective privacy management is not an easy activity in practice. It is becoming more and more of a struggle for organizations to comply with the changing privacy rules and regulations. Some of the struggles organizations may be faced with are setting up an incident response procedure, the reporting of breaches or the design and implementation of a clear and transparent communication process.

C-2016-3-Caspel-01

Figure 1. EU Regulation (2016/679): examples of personal information (red indicates sensitive personal information).

The privacy of the individual is subject to many rules and regulations of which the upcoming General Data Protection Regulation (GDPR) might be the most important one. Research conducted by the International Association of Privacy Professionals (IAPP) and TRUSTe reveals that 60% of the organizations participating in their study are very concerned about the upcoming GDPR (see Figure 2). To understand why these organizations are concerned, we need to understand what risks organizations face when their privacy management is not sound.

C-2016-3-Caspel-02

Figure 2. Concerns of organizations regarding the GDPR (www.iapp.org).

What Are the Organization’s Risks?

To answer this question, a study was conducted in the Online Services sector – a sector which exists solely because of the online market and is characterized by a high online presence. The focus of this study is the personal information of customers. Many of the online organizations easily collect more personal data of their customers than required and have to step up their privacy game in order to remain compliant. Even more important, as the privacy awareness of customers grows and competition is fierce, these organizations have to manage privacy effectively in order to gain the customer’s trust and leverage privacy as a unique selling point.

When privacy is not effectively managed, it can have various consequences. Perhaps most obvious, a data breach can occur where the organization loses personal data to a hacker, a disgruntled employee or a script kiddy. Additionally, in many countries the authoritative bodies are competent to conduct research into organizations if they have a reasoned assumption of misconduct. Both events can most importantly result in legislative penalties, erosion of brand and reputation, and increased surveillance of an authoritative body.

Legislative Penalties

The risk of legislative penalties is easy to understand: when an organization does not comply with the privacy rules and regulations of the country, an authoritative body may decide to fine the organization. In 2016, the new General Data Protection Regulation has been ratified which will come into effect in May 2018. If by that time organizations do not have their privacy management sorted out, the authoritative body may fine the organization with a fine of up to 20,000,000 EUR, or in the case of a global enterprise, up to 4% of the total worldwide annual turnover of the preceding financial year, whichever is higher. This makes the consequences of not having a sound privacy management directly quantifiable.

Erosion of Brand Reputation

The erosion of brand reputation is less quantifiable than a legislative fine. Many studies have been conducted to research the market reaction to a privacy breach. Privacy breaches have a negative impact on the market value of an organization: organizations lose out on business opportunities, their value on the stock market decreases, and individuals alter their buying patterns as they lose trust. Additionally, organizations are less attractive for employee candidates when the organization has been subject to a privacy breach.

Individuals, both customers and employees, have expressed concerns when it comes to collecting personal data (see Box 1). Individuals feel that an excessive amount of personal data is being collected and stored nowadays. They fear that data is being used for another purpose than originally collected for and that third parties are given access to this data. Because of these concerns and the vulnerable state an individual ends up in when providing privacy data to an organization, organizations are punished with lowered purchases and less job applications from employee candidates when they violate the individual’s trust. Though researchers question the sustainability of this change, the immediate result, at least in the short-term, is the erosion of brand and reputation.

Box 1. Market reaction to concerns of the individual.

Individuals have expressed concerns when it comes to collecting personal data and it reflects an increase of privacy awareness. The market is reacting to these concerns. More and more solutions are becoming available that enable individuals to take matters into their own hands, and provide individuals with opportunities to protect their online privacy. From applications that generate complex passwords and that store these passwords in a digital vault (for instance: OnePassword or KeePass), and solutions that let users mask their personal information, such as e-mail addresses, phone numbers and credit card numbers when buying from an online retailer (for instance: Abine Blur) to solutions that let users use the Internet anonymously (for instance: Tor or Tor Browser). On top of this, more and more encryption solutions are becoming available for people to encrypt, for example e-mails and files, without having to understand cryptography procedures or techniques (for instance: Telegram).

Increased Surveillance

A third result is increased surveillance. Organizations that have been subject to research conducted by the authoritative body, or organizations that have been the subject of a data breach, pose a higher risk when it comes to the protection of personal data. As a result, the authoritative body of the country might decide to monitor the organization more thoroughly.

An example of increased surveillance by the data protection authority is the punishment that the Federal Trade Commission (FTC) imposed on Google and Facebook. From 2012 until 2032, Google and Facebook have to conduct ten privacy audits each per year to ensure their processes are according to standards of the FTC. This is a result of a research the FTC conducted after they received complaints about unfair processing and deceiving statements. Not only do these privacy audits cost a lot of money, it also harmed the reputation of both companies.

Why Are These Risks Becoming More Relevant?

Recent developments have caused the likelihood and the impact of these risks to be higher than before. Technological developments allow organizations to collect, store, and use more personal data. Compared to a decade ago, there is more information available, and even other types of information are available. For instance, not only your name and address can be found online, but your bank account is also stored digitally, as well as your mortgage contract and potentially even your medical history. Additionally, the speed of exchanging data increases rapidly, and the costs to store data decreases significantly. Hence, collecting and storing more personal data online thereby increases both the likelihood of a privacy breach, as well as the impact.

Another development that increases the impact of a privacy breach, are changing rules and regulations as a result of the upcoming GDPR. The new GDPR will come into effect on May 2018, but the organizations subject to this study have all expressed concerns when it comes to meeting this deadline. The most important changes of the new GDPR are bigger fines, an obligation to report data breaches, and a set of new requirements, including privacy-by-design and mandatory privacy impact assessments (see Table 1). The changes require organizations to assess their current data flows, and perhaps change their privacy related processes in order to remain compliant.

Table 1. Most important changes of the new GDPR for organizations. [Click on the image for a larger image]

The Strategic Choices of Privacy Management

Organizations in the Online Services industry have cooperated in this study and demonstrated a scattered focus on their privacy practices. In general, the organizations focused on the process of collecting data, on the processing and retention of data, and on the disclosure to third parties. When going into details though, it became apparent that when it comes to customer’s privacy, organizations adopt one of the three perspectives. Adopting one of the three perspectives is a strategic choice which has a significant influence on the course of an organization’s privacy management. The first two strategic choices of privacy management appeared at an early stage and are widely known. However, over the course of the study, a fascinating third strategic choice emerged. Though this strategic choice is not widely known, it can be the unique selling point an organization is looking for in order to survive.

First Strategic Choice: Compliance Based Privacy Management

Compliance based privacy management strives to adhere to the rules and regulations. The organization finds ways to organize their privacy related processes in such a way that they will be compliant. Changes to privacy management are performed in an ad hoc fashion and only when changes in rules and regulations are being enforced by the authorities. An example of compliance based privacy management is informing individuals about their data which is being collected and for what purpose. Organizations are only allowed to collect an individual’s data once the individual has been notified about these two aspects. In addition to this, a lot of organizations use one or more third parties to manage their data. In case this “outsourced” data encompasses privacy data, the organization is legally required to draft a processing agreement between themselves and the third party. This agreement has to adhere to certain requirements, one of which is the notification of a data breach. Once the third party has suffered a data breach, it is important that the first organization is notified about this breach, so they can make an estimation as to whether this breach is of such a nature that they have to adhere to the data breach regulation. Each organization is required to notify the Data Protection Authority once privacy sensitive data has been compromised.

The privacy rules and regulations are quite extensive. Making sure the organization is compliant to the numerous privacy related rules and regulations therefore encompasses a variety of tasks: informing individuals about the data collection and its purpose, drafting processing agreements, handling possible data breaches, appointing a Data Protection Officer and the disposal of data in a timely manner. This list is not exhaustive: the privacy regulation encompasses a lot more. It is believed that striving for a compliant based privacy management practice is not an easy task and the research conducted by IAPP and TRUSTe shows that 44% percent of the organizations are still struggling with this. However, striving for even more than just adhering to the rules and regulation, might render interesting results for the organization.

Second Strategic Choice: Risk Based Privacy Management

The second strategic choice of privacy management is establishing a stabilized and continuous process, which is well-documented and covers all aspects of privacy management. This strategic choice can be adopted after the organization has accomplished compliance with the privacy rules and regulations of its country and thereby has the opportunity to mature its privacy processes. With this approach, organizations will shape their privacy management based on the risks they have identified. This risk based approach will help organizations to determine priorities and allocate sufficient budgets for the program.

Risk based privacy management is characterized by certain traits and processes. In contrast to the ad hoc nature of compliance based management where privacy management is only altered when rules and regulations demand it, is risk based privacy management a state where the organization is in control of its processes and applies continuous improvements. Changes are not just a result of changes in rules and regulations, but mainly a result of a pro-active approach of the organization to manage personal data in an ethical manner. Self-assessments, privacy impact assessments and periodic reviews help the organization to maintain a pro-active approach. Additionally, getting certified for a privacy audit (e.g. Privacy Audit Proof) may help the organization to maintain this status and pro-actively identify points of improvement.

Another important trait of the strategic choice of risk based privacy management is communicating the sense and urgency of privacy throughout the whole organization. Organizations will set up a privacy awareness program to explain privacy to its employees and provide them with guidance how to act. Additionally, the organization will have a whistle blowing hotline where employees can report malpractices anonymously. The organization can communicate its privacy policy throughout the organization as well by incorporating privacy policies in the HR processes. New joiners are informed about the privacy policies, and need to be made aware of the contents of the confidentiality agreement.

The organization has reached the strategic choice of risk based privacy management if their processes are mature, and the sense and urgency of privacy is well communicated throughout the entire organization. Improvements are not done based on changing rules and regulations, but based on a pro-active approach. It decreases the chance of identifying and implementing a change too late and thereby decreases the risk of a data breach or legislative penalty.

Third Strategic Choice: Customer Oriented Privacy Management

The first two strategic choices have been widely studied by various researchers. Though the second strategic choice is not easy to achieve, many organizations will establish a stabilized and continuous process and will thereby reach the state of risk based privacy management. For many organizations, risk based privacy management is then the end goal of their journey after which they maintain the quality of the processes, but do not improve further.

The first two strategic choices can be seen as “hygiene factors”. Even though these choices may result in an effective privacy management with a minimum chance of risks, they are not easily visible to the individual. Organizations that want to make a difference and want to leverage privacy as a business enabler, need to meet or even excel the expectations of the individual, since this is what privacy is all about. When organizations have reached compliance and processes are effectively managed, they need to begin to strive for something more: a customer oriented privacy practice. This way of managing the privacy practice excels as it focuses on the concerns of the individual.

C-2016-3-Caspel-03

Figure 3. Two top ways to decrease concerns of the individual (www.TRUSTe.com).

Research performed in 2016 by TRUSTe, a leading global privacy management organization, reveals that there are two ways to decrease the concerns of an individual when it comes to privacy: individuals having more easy tools to protect personal data and organizations being more transparent about how they collect data, and what they will use it for (see Figure 3). A customer-oriented approach is therefore characterized by the organization taking steps to increase transparency about the process of the processing of personal data and thereby meeting the expectations of the individual. The view of the organization switches direction from inside to outside. The organization focuses more on communication towards the customer: they simplify the text of the privacy notice and make it visually attractive. They do not tuck it away in some far corner of the website, but give it a prominent place on the website, or shape it in a comic right at the intro of an app. Additionally, the notice which is presented to the customer gets tweaked in a more customer friendly way. Organizations explain the purpose of the data collection not in text, but for instance in pictures or video, to improve the understanding of the customer (see Box 2). When choosing the second strategic perspective, organizations can use privacy certifications to identify points of improvement for their privacy management. When adopting the third strategic choice, privacy certifications are another way to be transparent to the individual and show the organization processes their data with due care.

Box 2. Examples of a customer centric approach.

A customer-oriented approach is characterized by aiming at the understanding of the individual, supported by simplified texts and attractive visuals. Examples are not yet bountiful, but some great examples can already be found on the internet.

Windows

Windows has updated their privacy statement during 2016. Instead of a long plain text page, they have opted for a more visually attractive overview of their statement. The statement is divided into different topics, which are all displayed in a clear cube. Notable about the statement is that the text is formed around the individual. The individual is personally addressed (“how we use your personal information”) and the statement is divided into questions which the individual might have.

C-2016-3-Caspel-04

Figure 4. Privacy statement on Microsoft.com.

The Guardian

The Guardian is one of the great examples. In clear and concise wording, they explain the highlights of their complex privacy policy, including essential principles as the purpose of the collection, proportionality, third party access and security. Their privacy policy is hard to understand for the individual, but their video explains it in simple wording. Together with the attractive visualization, the privacy policy is explained in an easy to understand manner. Everyone navigating to the website can view this video.

C-2016-3-Caspel-05

Figure 5. The Guardian’s privacy policy explained in a video.

LinkedIn goes a step further and supports its video with a webpage. It summarizes its privacy policy in three topics. These three topics are not only visualized in their video, but are also listed on the top of their privacy webpage. The video supports the webpage and the webpage supports the video. The video and the webpage refer to each other, together giving a complete overview to the individual. This makes LinkedIn another great example of the individual oriented approach.

C-2016-3-Caspel-06

Figure 6. LinkedIn’s privacy policy explained in a video.

For the third strategic choice, the customer orientation the organization adopts is key, focusing on explaining their privacy policy to customers as easily and conveniently as possible. The result is that customers value the transparency of the organization, their concerns decrease, and the reputation of the organization increases. Along with an improved trust relationship and possibly an enhanced reputation, there is a direct positive effect on sales as well. When the privacy policy is explained to the customer in an easy fashion, customers do not need to spend a lot of time reading. Spending a lot of time reading the privacy policy, which often contains many difficult sentences and jargon, can make the customer decide not to proceed viewing the website and the organization’s offering. Simplifying the privacy policy thereby will have a direct positive effect on the sales of the organization.

Forrester acknowledges and specifies privacy as one of the ten critical success factors for organizations in 2016 (www.forrester.com). The customer-oriented approach is not required for a risk based privacy management, and is also not demanded by any law, though it gives the organization the opportunity to make a difference, decrease the concerns of the individual, and use privacy as a competitive differentiator.

Conclusion

Privacy can be become the leverage that Online Service organizations need to survive in the highly competitive world. Individuals are increasingly becoming aware of the risks associated with revealing personal data to organizations and it can be quite a struggle for organizations to protect this data and comply with changing privacy rules and regulations.

In order for organizations to protect and manage personal data with due care, they need to make a strategic choice. Three strategic choices in privacy management have been identified: they are not mutually exclusive and can be adopted simultaneously (see Box 3). However, for many organizations, the first choice in privacy management, is becoming compliant. As privacy laws are rather complex, this is not a step that should be underestimated and organizations should reserve sufficient time and resources to support this strategic choice. When compliancy has been achieved, risk based privacy management might be the next choice for the organization. This strategic choice is characterized by continuous and stabilized processes and priorities are based on risk assessments. The organization recognizes that rather than just avoiding fines, risk based privacy management adds value to the organization by maintaining the data at a high quality (which can have beneficial effects on marketing activities) and being in control of the processes to reduce risks. Third is the fascinating identification of a step towards the individual which many organizations are not yet aware of. As the individual is increasingly becoming aware of their privacy, changes are required in the privacy management of organizations to explain the privacy policy to the individual and build a trustworthy relationship. Organizations are then leveraging privacy as a unique selling point.

Box 3. Where to start?

The sequentiality of the choices as presented is based on the observations in the Online Services sector. Many organizations might choose to steer their privacy management according to this sequence, as a compliance based approach provides a solid basis to build further privacy practices on. However, some organizations might decide to adopt them differently: an organization may choose for a customer centric approach in order to be transparent and aim for increased sales, while at the same time, the organization is still working on being compliant with the law. Non-compliancy is then combined with a customer centric approach. This results in the organization taking account of all measures that keep the individual well-informed, while behind the scenes, privacy management is not (yet) in order. This is a non-desirable state, as the solid basis resulting from being compliant is then missing. A customer-centric approach can therefore best be adopted simultaneously with, or following a risk-based approach.

Organizations must realize that neither of the strategic choices is easy to achieve and many organizations are still struggling with adopting the first strategic choice. However, in highly competitive times and with individuals being more aware of their rights of privacy, privacy management can become the differentiator the organization needs to be successful. Only when the organization adopts a customer-oriented approach and is transparent about their privacy processes, can a trustworthy relationship with the individual be established and can privacy become the unique identifier the organization needs. Therefore, organizations need to return to where it all began: the individual.

Box 4.

This article focuses on privacy management: the risks an organization faces and the strategic choices an organization might consider when it comes to privacy. Privacy is also concerned with the use of IT and therefore (technical) security. If you want to read more about the relation between privacy and security, an interesting read could be Privacy By Design: From privacy policy to privacy-enhancing technologies in Compact 2011/0 ([Koor11]).

References

[Forr16] Forrester, The 2016 Top 10 Critical Success Factors To Determine Who Wins And Who Fails In The Age Of The Customer, 2015.

[Guar14] The Guardian, Our privacy policy – a quick look (video), 2014, https://www.theguardian.com/info/video/2014/sep/08/guardian-privacy-policy

[Koor11] R.F. Koorn and J. ter Hart, Privacy by Design: From privacy policy to privacy-enhancing technologies, Compact 2011/0.

[Link16] LinkedIn, Privacy policy, 2016, https://www.linkedin.com/legal/privacy-policy

[Micr16] Microsoft, Privacy statement, 2016, https://privacy.microsoft.com/

[Stew02] K.A. Stewart and A.H. Segars, An empirical examination of the concern for information privacy instrument, Information Systems Research, 13(1), 2002, pp. 36-49.

[TRUS15] TRUSTe, Preparing for the EU General Data Protection Regulation, 2015, https://iapp.org/media/pdf/resource_center/TRUSTe_GDPR_Report_FINAL.pdf

[TRUS16] TRUSTe, 2016 TRUSTe/NCSA Consumer Privacy Infographic US Edition, 2016, https://www.truste.com/resources/privacy-research/ncsa-consumer-privacy-index-us/

Security Challenges Associated With SAP HANA

Traditional risks associated with the technical security of SAP R/3 systems are generally unknown and neglected. SAP HANA introduces additional confidentiality, integrity and availability challenges to the SAP business suite. HANA is becoming the central data hub for interfaces and users, therefore logical access controls are vital for the security of the platform. The introduction of SAP HANA can be leveraged to eliminate previously neglected security vulnerabilities and offers the opportunity to design a holistic SAP security program.

Introduction

Due to the expanse of SAP functionalities and products, organizations are inadvertently increasing the number of access paths to their critical data assets. In addition, SAP embraces new technologies, which exposes SAP to all the security risks inherent to these technologies. Research has shown that these risks are only mitigated to a limited degree ([Scho13]).

This article studies the security implications associated with a recently introduced SAP technology, specifically related to in-memory performance technologies (HANA). An introduction to HANA will first be provided. After that, we study key changes to the IS/IT architecture and their impact on the SAP security concept. We conclude with a reflection on the recently released SAP security baselines and emphasize key security priorities.

C-2015-4-Schouten-01

SAP HANA

Companies reflecting on their future SAP landscape and strategy will engage with SAP S/4HANA (formerly: High Performance Analytic Appliance). SAP Business Suite 4, or SAP HANA (hereafter: HANA), is the primary product of SAP’s strategic growth initiative. The technological leap that accompanies HANA can be compared to the migration from R/2 to the currently known R/3 or the NetWeaver platform. As an in-memory, high performance data and application platform, HANA promises real-time business. Because data is stored in-memory (RAM), it can be directly accessed by analytic and transactional applications, that sit on top of HANA. From an architectural perspective, HANA can empower separate applications (e.g. SAP BW/BO) as a relational database in a classical 3-tier architecture or can be enabled to utilize the recently enabled SAP business suite S4/HANA. The eminent architectural novelties that HANA introduces (refer to Figure 1) require a revised view on the information security risks related to SAP. Before studying the impact on IS/IT security, we elaborate on major changes that the HANA technology introduces to the current SAP landscape in the section below.

C-2015-4-Schouten-02

Figure 1. SAP HANA architecture overview.[http://saptrainings.com/sap-hana-online-training/]

Key Changes

HANA introduces major changes in terms of system architecture compared to SAP R/3 (that is supported by a classic database setup). We recognize two common change areas, based on the various HANA implementations studied:

1. Real-Time Analytical Access

The traditional separation between Online Analytical Processing (OLAP) systems, such as SAP BW, and Online Transaction Processing (OLTP) systems, such as SAP ECC is revoked. This improvement introduces real-time analytical access to transactional data, resulting in new use cases and (predictive) analytics scenarios or mobile applications. HANA is designed to be one (big) data layer/platform for all applications. Thus, HANA is connected to many more interfaces compared to the classic 3-tier architecture setup, in which the application server connects to the database using a communication user. In the case that HANA is used solely as a database, logical access controls are mainly focused on HANA’s security-related features related to the restriction of (administrative) access.

2. Single Source of Truth – Data Layer

HANA is both an application and a data processing platform at the same time. Thus, the classical 3-tier architectural approach, i.e. separation of data presentation, processing and storage layers, become obsolete. Within HANA, the database is an integral part of the application. Therefore, new user groups, such as developers or end users, are very likely to work directly on the embedded database of HANA. Business logic, data processing and SAP program development is moved to the data layer. Consequently, all customized ABAP development needs to be rewritten to be highly performant. ABAP is the proprietary business programming language of SAP. The HANA platform can be considered as the future development platform for SAP programs.

The implementation of HANA introduces additional network channels, accounts, user groups, use cases and presents novel ways of accessing and developing SAP systems. HANA technology implicitly increase the attack surface to sensitive and critical data. As HANA is an application and data processing platform at the same time, the traditional 3-tier architecture and corresponding lines of defense are abandoned. Confidential data can be analyzed on a real-time basis, using well-known tools. The deployment of HANA inevitably requires a thorough risk analysis, assessment and treatment. An additional challenge is that the architectural changes are gradually evolving. HANA implementations usually start by enabling ERP on HANA, followed by the entire SAP (and non-SAP) systems running on HANA. Thus, the above-mentioned security risks are not necessarily applicable for a classical 3-tier architecture. However, it is vital to consider the future landscape when analyzing the risks and designing the security architecture during an initial HANA implementation. The next chapter provides guidelines, support and techniques on how to deal with these new security considerations.

Key Aspects

Most of the time software projects are driven by strong business needs and the provisioning of new, competitive functionality. The implementation of security requirements is often an afterthought within this process. A technology change, such as the implementation of HANA, provides companies with the perfect opportunity to implement previously dismissed security measures ([Scho13]).

Moreover, many companies lack a thorough understanding of the architectural and business process changes which HANA introduces. Often, HANA is perceived as “just another database” by the IT department thus overlooking the new use cases and associated risks. Our experience with HANA implementation projects show that the development of HANA information models and applications move closer to the business. This in turn requires awareness in secure development practices for a broader audience. Therefore, all employees should be aware of HANA becoming the central application and development platform, and the organizational changes and associated risks, in order to effectively implement and run SAP HANA.

To address security requirements and risks throughout the entire lifecycle of a HANA roll-out, the creation of a holistic SAP HANA security concept is required. SAP has released a HANA specific security guide which elaborates on HANA security configuration topics ([SAP15a]). Additionally in 2015, the SAP Security Baseline has been updated with the latest security recommendations for SAP HANA ([SAP15b]).

In Table 1, we have outlined a non-exhaustive list of recommended critical configuration settings that focus on common (neglected) security flaws that are required for a secure SAP HANA roll-out.

C-2015-4-Schouten-t01

Table 1. Examples of recommended controls for a secure SAP HANA roll-out.

While all of these topics are important, we would like to elaborate on the “Network and Communication Security” and “Access Control” areas in more detail as they are vital for the security of the platform and introduce significant changes to security.

Network Security

In order to implement a secure system, an overview of all the components that are connected to SAP HANA is necessary. Hence, a well-defined network topology or application architecture needs to be in place, which can be used to configure Access Control Lists (ACL). Network access to HANA should be restricted to dedicated, authorized communications channels only.

Access Control

Authentication

Well-known password parameters from the R/3 concept have been re-shaped within HANA security rules. A “password_layout” rule has been introduced to capture and verify password complexity requirements. The default value of this parameter “A1a” indicates that the password must contain one Uppercase, Numeric and Lowercase character as a minimum.

Authorization

Access controls are vital for the security of the platform due to the fact that far more users and systems have access to SAP HANA compared to traditional SAP databases. The fundament of controlling access to data in HANA is a detailed authorization concept.

In principle, access to a SAP HANA database is determined via the privileges granted to a user either directly or encapsulated within roles. Five different types of privileges can be distinguished:

SYSTEM privileges for administrative activities.
PACKAGE privileges for working with the SAP HANA repository.
OBJECT privileges for access to database objects such as the business schema holding the data.
Analytical privileges to further filter access to data provided by information models.
Application privileges for managing the access to an XS application (web application server running on the HANA platform).

In theory, high-level guidance for the development of an authorization concept is that HANA administrators mostly require SYSTEM privileges, information and role modelers require a combination of PACKAGE and OBJECT privileges (e.g. _SYS_BIC) and (business) users leveraging information models commonly require OBJECT and ANALYTICAL privileges.

Based on KPMG’s good practices, several key principles can be applied for the definition of an appropriate authorization concept. This is a non-exhaustive list based on KPMG’s proprietary knowledge:

Design should follow “need-to-know” principle.
Design Segregation of Duties (SoD) controls according to business needs.
Encapsulate privileges in roles which are designed in accordance to the job function.
Use repository roles instead of catalog roles. SAP HANA provides two different approaches for role modeling; repository roles and catalog roles. The usage of catalog roles should be avoided as these roles (1) are not transportable, (2) do not provide versioning, (3) require a super user for role management and provisioning and (4) are owned by the user who creates them. This principle is not applicable to repository roles.
Develop (repository) roles in HANA development environment and use transport system for its transport into test and production systems.
Avoid the use of development rights in production (mostly granted via PACKAGE PRIVILEGES).
Avoid the use of pre-delivered SAP catalog roles such as MODELING.
Avoid the use of critical privileges such as ROLE ADMIN, _SYS_BI_CP_ALL and DEBUG.
Avoid the use of critical privilege combinations such as USER ADMIN and ROLE ADMIN.

Due to the introduction of HANA, Segregation of Duties matrices need to be updated to reflect the SAP HANA authorization design. Moreover, it is vital for the security of the whole system that technical interface/communication users follow the principle of least privilege, as HANA serves as the central data hub with numerous interfaces ([SAP14]).

Conclusion

A revised view on information security governance during the implementation of SAP HANA is required, due to the eminent architectural novelties that HANA introduces. The implementation of HANA results in the extension of sessions and implicitly introduces novel access paths to sensitive and critical information. As HANA is both an application and data processing platform, the traditional 3-tier architecture and corresponding lines of defense are abandoned. HANA becomes the central data hub for interfaces and users, therefore strong and/or granular access controls are vital for the security of the platform.

The fundament of controlling access to sensitive information in HANA is a detailed authorization concept and a revised authorization matrix. Additionally, an overview of all the components that communicate to SAP HANA is necessary. Hence, a well-defined application architecture needs to be in place, which can be used to restrict network access to dedicated, authorized communications channels only.

The implementation of HANA enables organizations to eliminate previously neglected security flaws and offers an opportunity to design a holistic SAP security concept. The HANA security guide and SAP security baseline should be included throughout the entire lifecycle of SAP HANA.

References

[ERPS15] ERPScan, Static encryption keys as the latest trend in SAP security, press release, June 18, 2015, http://erpscan.com/press-center/news/static-encryption-keys-as-the-latest-trend-in-sap-security/.

[SAP14] SAP, How To… Define Standard Roles for Administrators and Developers in SAP HANA Database, SAP How-to Guide, March, 2014, http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c02c2004-899d-3110-8488-b3ff8362bbf6?QuickLink=index&overridelayout=true&59180354403522.

[SAP15a] SAP, SAP HANA Security Guide, July 1, 2015, http://help.sap.com/hana/sap_hana_security_guide_en.pdf.

[SAP15b] SAP, Security Baseline, May 5, 2015, https://service.sap.com/~sapdownload/012002523100003655872015E/Security_Baseline_Template.zip.

[Scho13] T. Schouten, A False Sense of Security; Auditing (Beyond) the SAP Production System, University of Amsterdam, 2013.

Big Data Analytics & Privacy: How To Resolve This Paradox?

Mind the hype. Big Data is the next big thing in the world of IT, partly as people are becoming increasingly aware of its potential to impact the business world and society as a whole. In addition, people are awaking to the powerful possibilities that combining structured and unstructured, internal and external data holds. The opportunity this offers to perform advanced analytics, or “Big Data Analytics”, provides insight into the various outcomes of Big Data Analytics, and particularly the impact it could have on the Privacy of individuals. In this article, we elaborate on the Privacy challenges with Big Data by looking at Big Data applications from four continents, and examine how the respective legal frameworks relate to those Big Data uses.

Introduction

From predicting criminal behavior to gene-based medical breakthroughs, from location-based restaurant recommendations to customer churn predictions, the benefits of Big Data in everyday life are becoming self-evident.[Big Data is high-volume, high-velocity & high-variety information assets that demand cost-effective, innovative forms of information processing for enhanced insight & decision-making (Gartner).] Likewise, organizations see advantages in applying so-called “datafication”[Datafication is a modern technological trend turning many aspects of our life into computerized data and transforming this information into new forms of value (see also [Maye13]).] and implementing Big Data programs as part of strategic business models. There are opportunities to gain a competitive advantage, to get to know your customer behavior better and to identify new business areas.

However, concerns about Big Data are also growing. Customers are increasingly wary of the unlimited data hunger, extensive use, and potential abuse, of personal information by profiling and being provided personalized online ads or even personalized prices based on online tracking. Regulators are enacting and trying to enforce laws that conflict with widespread personal data use.

In this article, we address successful and unsuccessful applications of Big Data from a Privacy perspective. After describing some examples of how organizations are currently using Big Data, we look at the Privacy challenges with Big Data in different geographic areas. First, the legal Privacy framework in each region is discussed, followed by an example of how a Big Data implementation led to a Privacy failure. We conclude by presenting a number of potential solutions and conclusions with a view to dealing with Big Data in a Privacy-compliant manner.

How Are Organizations Currently Utilizing Big Data?

Companies have been collecting data for years, and as the technical capacity increased, so did the volume. In our age of inexpensive processing equipment, the size of the datasets involved are difficult to comprehend. For example, it was reported in 2012 that 90% of all available data had been created in the previous two years ([John12]).

Big Data sets are either too large or too versatile to be analyzed using traditional relational and multidimensional database techniques or commonly used software tools to capture, manage, and process the data within a reasonable elapsed time ([ISAC13]).

Big Data is not confined to a single industry. Organizations across all industries recognize Big Data’s value and seek to harness its potential. For example (see also [Klou15] and [Maye13]):

Retail companies use Big Data to improve services and products through customer analytics, customer behavior, sentiment analysis, profiling and segmentation.
Governments use Big Data analytics to gain insight into citizen activities and requirements, detect fraud or abuse of services, focus “nudging” on specific behavior, strengthen national security and better allocate government resources.
Financial institutions are using Big Data to better identify their customer markets and assess risks, including creditworthiness and default rates.
The travel industry & public transport sector is identifying current and potential loyal and high value customers, by analyzing travel patterns and frequency across both personal and professional platforms. Recent analytics predict travel delays before they even happen.
Insurance companies are introducing risk-based ratings (with higher premiums) and efficiencies through the use of Big Data analytics, even by placing in-vehicle data recorders for analyzing driving behavior and events in real time. Based on such analysis and profiling, most claims may be processed automatically through Straight-Through Processing, whereas others are set aside for additional manual review.

As Big Data continues to transform industries, organizations face a growing demand for talent to help them take advantage of Big Data’s opportunities. It is clear that “organizations which benefit from Big Data & Analytics will have a competitive edge when it comes to better and faster business decisions” ([KPMG13]). However, most organizations are still struggling to make use of Big Data effectively, due to a lack of high quality data, skilled data scientists, tooling, integration, and well-founded decision-making ([KPMG14]). Currently, most Big Data analytics are focused on operational and tactical questions; in effect, not many strategic or social issues have been addressed by private or public organizations.

Example of successful Big Data – Europe

An example of a successful Big Data implementation concerns the coronation of the new King in the Netherlands on 30 April 2013, when Amsterdam experienced one of its busiest days in history. Throughout the city, multiple performances and other events were organized, attracting an estimated total of 750,000 visitors to the inner city of Amsterdam ([ANP13]).

Holland’s largest news website placed a widget online that visualized the intensity and movement of the crowds in the streets. Important to the concept of the widget was that of “Privacy by design”. The widget functioned by receiving antenna data from the mobile telecommunication network on the number of users connected to a cell.

The user’s Privacy was safeguarded as only aggregated information from the antennas was gathered that merely specified the number of connections for each antenna at each point in time. The data did not specify any additional information about the users of the telecom network and therefore the data could not be related to an identifiable individual.

C-2015-4-Koorn-01

Figure 1. Crowd control visualization based on Data Analytics.

What Are the Privacy Challenges With Big Data?

An argument that soon gained impetus as the attention for the potential of Big Data was increasing, was the impact it could have on the Privacy and Security of individuals. The massive collection of data and the interrelations that can be derived with Big Data, could lead to detailed insights into locations, specific consumer interests and human behavior for Big Data processors, something the individuals concerned might not even be aware of but would be perceived by them as a breach of their Privacy.

When it comes to using data analytics effectively for predicting human behavior, there are quite a few challenges ([Stro15]):

Human psychology of cognitive inertia: people are inclined to resist change and to revise their assumptions.
Information overload and quality: more data does not mean better data, especially when internal and external data sources are combined. Analyzing unbalanced data or data without the context may lead to prejudices, bias or incorrect conclusions.
Ability to make sense of behavioral data: deriving value from large volumes of data, for instance when analyzing data about emotions and sentiments, which are “scraped” off social media by market research companies.

As a consequence, even while data scientists are attempting to outsmart us, individual human behavior might be too complicated to predict accurately.

Privacy Legislation Affecting Big Data

The processing of personally identifiable information (PII)[The original scope of ‘Personally Identifiable Information’ was sufficiently broad when the European Privacy regulation was introduced: in certain circumstances it would include IP addresses ([Zwen13]). Since then, Working Party 29 have published a number of opinions related to the scope of the definition ‘personally identifiable information’ (http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2007/wp136_en.pdf). It can be concluded that the scope of the definition of personally (identifiable) information as used within the European Commission, is becoming increasingly wider ([Cuij12]).] is subject to strict regulations in most, if not all parts of the developed world, in order to protect the Privacy of individuals. Making use of Big Data is a means of processing and is therefore subject to Privacy regulation in cases where PII is concerned ([Vier12]). For instance, in the EU the current Data Protection Directive requires organizations that use automated decision-making to “produce legal effects”, such as not granting a mortgage based on programmed rules, so as to provide notice and to allow for human intervention.

In some parts of the world, applicable laws have been updated with a view to responding to collection practices made possible by new technology, namely data-gathering tools such as social media and mobile applications.[The FTC revised the COPPA requirements in 2013 to include Third Parties such as advertising networks covering unique IDs in cookies, along with IP addresses and device identifiers which can “recognize a user over time and across different sites or online services.”] The draft EU General Data Protection Regulation specifically mentions profiling, and that explicit consent is needed when profiling can significantly affect individuals (by positive as well as false negatives). If the data is anonymized or pseudonymized or profiling serves the “performance of a contract” or adequately safeguards the “legitimate interests” of individuals, in which case explicit consent is not required by law. Obtaining and maintaining explicit consent from each individual is usually an administrative hassle and – as most online users automatically click the Agree button to give their permission – is not as strong as an organization proving its overall Privacy accountability ([EDPS15]).

Under most Privacy regimes, the processing of PII is only allowed in circumstances where there are unambiguous legal processing grounds. Important in the processing of PII is that the cause and processing ground need to be established up front, in order to process PII in a compliant manner. One or more legal grounds need to be established per processing objective. In such a case, the ground for processing only concerns the processing for that objective. For example: data which is gathered with a view to carrying out a mutual agreement, such as billing by a telecom provider, may not be used for an additional, not closely related cause, like using Big Data methods to determine which (types of) callers call most frequently depending on varying marketing triggers. In short, PII data that is originally gathered for a legitimate purpose may not be reused for Big Data purposes without a separate processing ground or a purpose that is sufficiently “comparable” or “compatible”. In practice, this often poses a problem for the party aiming to use Big Data techniques ([Moer14]).

A solution that is often sought by parties willing to use Big Data in order to overcome the restrictions of Privacy legislation, is anonymization (see also section “Potential Solutions to Big Data Privacy Challenges”). Since Privacy legislation is only applicable to PII, simply removing or “masking” the PII fields such as name, address, birthdate and any ID numbers, may appear a good solution for avoiding the restrictions of Privacy legislation. However, in practice this solution will often prove inadequate ([EC14a]). First of all, with a large dataset, spontaneous recognition of an individual may still be possible ([Berk14]). Furthermore, not only directly identifiable data, but also indirectly identifiable data (“indirect inheritance”), fall under the scope of Privacy regulation. Data elements such as name and address are considered to be direct PII. Data elements that cannot be linked directly to an individual but can be traced back to an individual by performing deeper analyses on the data or by linking with additional data elements, are considered indirect PII. This indirect PII is also subject to all requirements in current and upcoming Privacy legislation.

Big Data & Privacy Case Study US – Target

Target is a well-known and early user of Big Data’s predictive powers, having correctly predicted a teenager’s pregnancy before her parents were even aware of the addition to the family ([Hill12]). Target’s datasets were therefore a highly visible and valuable source of information, and the subsequent breach it suffered of over 70 million customer records (including 40 million credit card numbers) resulted in significant damage to its finances and reputation. Target’s systems were breached by hackers using credentials stolen from a third party providing heating, ventilating, and air conditioning (HVAC) services, and the presumed Russian hacker has not yet been identified. Target’s security team received an alert that there was malware on their systems; however, they did not act on the notification and soon millions of records were leaking from their systems. Senator John Rockefeller stated “I think we can all agree that if Target – or any other company – is going to collect detailed information about its customers, they need to do everything possible to protect it from identity thieves” ([Rise14]). The CEO was fired; its shoppers were slow to return; and its data-breach costs have climbed to a quarter-billion dollars ([SCTi14]).

Currently, the US White House has issued a report on Big Data and Privacy ([Whit14]) and is proposing a federal Privacy Bill of Rights.

Big Data & Privacy Case Study EU – TomTom

A Big Data project with geo-location data of individuals has led to serious Privacy challenges under the EU Privacy regime. De Montoye et al. demonstrated that when dealing with individuals’ geographic location data, in a dataset where the location of an individual is specified hourly, the vast majority of the user’s identity can be derived based on less than five different location measurements ([Mont13]). This clearly shows how data which may not be perceived as such, could in fact be indirect PII and thus in scope for the EU Privacy legislative framework.

Dutch navigation provider TomTom experienced a Privacy challenge with the processing of geo-location data first hand, when Dutch DPA ruled that TomTom was in breach with EU Privacy legislation. TomTom subsequently received public criticism for not paying due respect to users’ Privacy. For the purpose of navigation, the TomTom device obviously processes the user’s geo-location data. Apart from the processing during navigation, historical data of previous use is also stored in the TomTom device. You could argue that if all data is retained in the device, there can be no major Privacy risk. Yet, newer TomTom devices are connected via the Internet and upload the user’s geo-location real-time to a central server in order to calculate traffic intensity and provide better navigation advice. With previous TomTom devices that are not online, the user’s historical geo-location data is uploaded when the user connects the device to the computer to perform updates.

The TomTom devices asked for the user’s consent to process geo-location data, but the Dutch DPA ruled that the consent did not suffice, as it was not specific enough. In consequence, there was no legitimate ground for the processing and TomTom was in breach of legislation. TomTom followed up immediately by requesting new consents to the whole user community where this applied. The Dutch DPA subsequently ruled that TomTom now possessed the correct consent for processing the relevant data.

TomTom experienced another Privacy incident when it was publicized that it was selling traffic data including historical speed to several third parties. Data recipients included local and national governments. It emerged that the Dutch police also used that dataset as an additional argument for placing speed cameras at locations where the average speed was too high. However, an investigation by the Dutch DPA showed that all traffic data was anonymized and aggregated, and that no individual data was sold. Even so, TomTom decided to alter their licensing agreements with data recipients to curtail this type of usage. Currently, TomTom is a leader with its privacy practices, according to the Mobility Data Analytics study by the Government Accountability Office ([GAO13]).

Big Data & Privacy Case Study New Zealand – Sensing City

Data protection in New Zealand is governed by the Privacy Act 1993, which exists alongside a range of industry codes including health, telecommunications and credit reporting, and other relevant legislation such as the Statistics Act 1975. The New Zealand Privacy legislation is principle-based, being influenced by the 1980 OECD Guidelines on the Protection of Privacy and Trans-border Flows of Personal Data. The European Union recognized the New Zealand Privacy Act as providing an adequate standard of data protection for the purposes of European law ([EC12]).

However, the advent of Big Data presents some challenges to these Privacy principles, especially as it is becoming easier to re-identify personal information from anonymized datasets and predictive modelling. A 2011 review by the New Zealand Law Commission did not recommend any fundamental changes to New Zealand’s principle-based legislation, but has recommended a number of changes which, in the words of the New Zealand Privacy Commissioner, “would power up Privacy law to meet the challenge of protecting New Zealanders’ personal information in the digital age.” ([Priv11])

In December 2013, the Ministers of Finance and Statistics established a New Zealand Data Futures Forum to explore the potential benefits and risks for New Zealand of sharing, linking and using data. Privacy is recognized as an integral part of the future use of Big Data. In its July 2014 report, the New Zealand Data Futures Forum concluded that “there are huge economic, social, environmental and personal opportunities for New Zealand if we can strengthen trust, control and inclusion in the data-use ecosystem.”

How Big Data can be used in a Privacy-compliant manner became apparent when the “Sensing City” was designed. Not only did the devastating earthquakes that hit the Christchurch and Canterbury region of New Zealand in 2010/2011 destroy the lives and livelihoods of tens of thousands, they also caused widespread damage to infrastructure and property in the region. Innovation and future-proofing the city have become some of the underlying design principles of the extensive rebuilding program. Planners have looked at the work of architect Roger Dennis to develop Christchurch as a Sensing City. The Sensing City initiative is based on transforming raw (Internet of Things) data centered on people and objects within the city into valuable information products. Data is combined and analyzed to drive the future applications, services and decisions in a wide range of sectors. Real-time open data provided by Sensing City has the potential to add immense value to local business and the lives of Christchurch citizens through the range of services it creates.

Big Data & Privacy Status – Africa / South Africa

Unlike the EU, there is no regional mandate within Africa for countries to implement laws ensuring the protection of personal information. Most African countries have yet to introduce such Privacy legislation. However, 17 countries that have introduced Privacy legislation have adapted legislation that is by and large similar to the Privacy laws found in Europe, Latin America and Asia. These laws are still in their foundational stages, due to the lack of established regulators. Furthermore, the lack of regional guidance for the development of Privacy laws has resulted in some inconsistencies between Privacy laws in Africa in respect of the legal basis for the collection and use, database registration, breach notification, and the cross-border transfer of personal information ([Rich14]).

The right of individuals to Privacy is founded in the Constitution of the Republic of South Africa Act 108 of 1996; it is supported by common law and various other pieces of legislation. However, although comprehensive Privacy legislation has been laid down in the Protection of Personal Information Act 4 of 2013 (POPI Act), it is yet to become effective in full (Note: some sections of the POPI Act relating to the creation of the Information Regulator and the guidelines for the development of data protection regulations are now effective). The POPI Act prescribes the conditions for the lawful processing of personal information by both public and private entities. Although the legislation has in effect been passed, there is no obligation for organizations to comply. Once the POPI Act is effective in its entirety, organizations will have a one-year grace period to comply with its conditions.

Although the POPI Act is rather similar to European and UK Privacy laws, being based on the OECD guidelines for the fair processing of personal information in respect of: accountability, notice, choice and consent, purpose specification, security safeguards, data quality and participation, it has some unique characteristics that play an important role in Big Data Analytics, including the following:

requirement for the protection of personal information that uniquely identifies both natural and legal persons;
requirement that only the minimal amount of personal information be collected to achieve a specific business purpose;
specific circumstances under which specific personal information (such as health information, sexual orientation, political affiliation, and race) , including children’s personal information, may be processed;
minimum requirements for the transfer of personal information across borders;
requirement for fair treatment of individuals in automated decision-making processes (e.g., deriving a risk profile for an individual through automated processes);
obligations for organizations to notify and obtain authorization from the Information Regulator for certain processing activities.

Within the South African context, organizations are yet to realize the benefits of Big Data, as there are only few organizations using Big Data for strategic decisions, risk management, and/or predictive modelling. Currently, South Africa remains relatively immature when it comes to the utilization of Big Data by organizations and its Privacy framework. The legal framework provides opportunities for Big Data use, however. This, in its turn, presents a unique opportunity for South African organizations to begin building their Big Data capability in conjunction with the upcoming Privacy legislation and use the conditions for the lawful processing of personal information, as prescribed in the POPI Act, in the context of their Big Data initiatives.

Big Data & Privacy Status – Japan

Big Data as well as regulatory Privacy developments in Japan are still in their early stages and appear slow in comparison with other countries. To counteract this, the Japanese ministry of Economy, Trade and Industry (METI), which is in charge of Big Data utilization, has developed a national strategy to accelerate utilization and increase international competitiveness driven by Big Data. On June 2014, METI established the “Strategic Council for Creating Data-Driven Innovation”, in which more than 200 enterprises participate, to accelerate the collaboration between the government and enterprises with regard to data utilization.

As a result of the increased efforts of METI and Japanese enterprises, a number of Big Data initiatives have recently been developed. Some of these initiatives amount to the following:

analysis of client-activity logs for an automatic selection of advertisements based on client attributes – by a web service company,
automatic abnormal pattern-matching in production line for a cost reduction of defects – by a precision equipment manufacturer,
vehicle traffic information analysis for the provision of accurate traffic information in case of incidents – by an automotive manufacturer.

One of the reasons for the slow uptake of Big Data in Japan is that enterprises are reluctant to use personal data due to the negative popular view. Another reason is that the Japanese legislation regarding Privacy-compliant use of Big Data is ambiguous and still subject to change.

The Japanese Act on the Protection of Personal Information was developed in 2003 and became effective for the private sector in 2005. The act stipulates the responsibilities of national/local governments and obligations of data processors when it comes to protecting personal information, but not the Privacy rights of data subjects. The Act is supplemented by guidelines established by various ministries in charge of their respective industries. In the Act, no rules for the international transfer of personal data are included.

Since January 2015, the congress has been in discussion to modify the Act to ensure that it covers how personal data should be used by various businesses. In addition, alignments with major Privacy and data protection regulators in other countries are currently taking place. Congress is proposing to create a definition of non-personal data and an organization to interpret the fine line between personal data and non-personal data on a case-by-case basis and to regulate obligations for handling non-personal information, which would be less restrictive than personal information.

In addition to the Act on the Protection of Personal Information, Japan has the Act on the Use of Numbers to Identify a Specific Individual in the Administrative Procedure. The objective of this Act is to make administrative procedures efficient by using an Individual Number (“My Number” in Japanese) and a Corporate Number for identification. As of October 2015, an Individual Number is assigned to individuals who have Japanese residency. As the Individual Number is categorized as Specific Personal Information, it will also be subject to the Act on the Protection of Personal Information.

Potential Solutions to Big Data Privacy Challenges

Based on the legal Privacy framework in the light of Big Data and the examples in different parts of the world, we can identify a number of potential controls for dealing with Big Data in a Privacy-compliant manner. These are:

Data Governance & Retention

Underlying any Big Data program, a data governance structure must be established that provides clear directions at to how the data is to be handled and protected by the organization. This program begins with a clear organizational structure around data governance (e.g., who is data owner or data steward/custodian, who is responsible for protecting the data), followed by additional key components such as policies, standards and procedures, including critical elements such as data use monitoring, data retention and data destruction. Preferably, data governance is translated and codified in a standard, in guidelines or in a framework (de-facto or de-jure). Several organizations are working on Big Data Privacy standards and guidance, such as ISO/IEC (see [ISO14]), NIST/IEEE (Big Data Public Working Group), Cloud Security Alliance (Big Data Working Group), UK’s Information Commissioners Office ([ICO14]), Working Group 29 of the European Commission ([EC14b]), and the Information Accountability Foundation ([IAF14]). Another avenue is the development of a Professional Code of Conduct for data scientists to stimulate ethical data use and to avoid data analytics cherry-picking.

Compliance

Organizations must identify and understand the Privacy and – in some countries – (cyber) security regulations that apply to the data they store, process, and transmit. Similarly, they are also responsible for compliance with the contractual provisions contained within their agreements with third parties and other service providers, as well as their own Privacy policy. Therefore it is essential that organizations establish a Big Data compliance program that provides the necessary overview when it comes to the monitoring of compliance with regulatory and contractual commitments.

Compliance requires the development of a comprehensive Data (Privacy) Control Framework and risk-based roadmap for implementation. Companies can then take advantage of automated controls based on such a standard and transition from manual efforts to ensure ongoing compliance.

In a previous article, we discussed the different Privacy by Design options that can be applied for automating (preventative) Privacy controls ([Koor11]).

Data Use Cases & Data Feed Approval

Organizations must manage their Big Data usage through the identification of potential use cases for the data. Once an organization understands the potential use cases, it can mature its Big Data program through the implementation of a formal use-case approval process, which includes formal risk assessments such as a Privacy Impact Assessment prior to the adoption of new data feeds. Key considerations in the adoption of any new data feed are the quality of the dataset and the potential risk for re-identification, which increases when existing data feeds are combined with other data feeds. With respect to the limited quality of datasets involving human behavior, an upcoming approach is to just add substantially more data in order for this large quantity to resolve the quality problem. This approach is practiced and studied by researchers at Google ([Hale09]).

Consent / Permission Management

Customer consent management is critical to a successful implementation of any Big Data governance regime. Consent is not required for every Big Data project, so if the organization can prove “compatible use” or “legitimate interest” (see [EC14b]), it may do without. Unfortunately, obtaining online customer consent has degenerated to a clickable Privacy control.

Customer consent requires the following components:

Transparency – Organizations should provide their customers with a clear understanding of the information the organization collects and how it will be used.
Consistency – Organizations should provide consistent consent mechanisms across all products, and register Big Data preferences upfront.
Granularity – Organizations should allow customers to provide or withdraw their permissions at the individual device level, not only at a larger account level.

Access Management

Given the amplified size and scope of Big Data, organizations must effectively control who in the organization has access to the datasets. This requires a comprehensive and granular access management regime including review and approval of new user access requests and periodic reviews of existing user access to ensure that privilege requirements meet security and compliance requirements. Finally, organizations should adopt segregation of duties where access to systems is based on job functions. Organizations can automate the process by using policy engines or access management tools to implement Role- or Attribute-Based Access Controls (RBAC resp. ABAC). This will help them make dynamic access decisions and integrate with existing tools and directories for provisioning and certification. Each extensive data warehouse with identifiable personal data is a Privacy risk in itself (“single point of success or failure”), and without strong access controls and segmentation, a single disgruntled employee or hacker might create a major Privacy breach.

Anonymization & Pseudonymization

Anonymization means removing all personally identifiable information (PII) from a dataset and permanently turning it into non-identifiable data. Well-designed anonymization or data-masking is critical to the long-term use of Big Data while maintaining the Privacy of the original datasets. In practice, achieving full anonymization in large datasets is very challenging; the outcries about the publicly accessible and anonymized internet search data (AOL in US) and health data (care.data of the National Health Service in the UK) demonstrate that by means of data mining and cross-referencing several identities could be derived. Therefore, using strong anonymization close to the data source and quantifying the risk of re-identification should be part of each organization’s approach ([Koot12]). Alternatively, the entire data analytics can in some instances be positioned at the data source, which means the results exchanged for further central processing are identity-free.

Halfway fully anonymized data and identity-rich personal data is the concept of pseudonymization. Pseudonymization refers to a procedure in which identifying data will be replaced with a specific, non-reversible hashing algorithm by encrypted data (pseudo-ID). This algorithm can always calculate the same pseudo-ID for the same person, so that information about that person, derived from different sources or over a longer timespan, can be combined (longitudinal research). This differentiates pseudonymization from anonymization, where combining personal data is impossible.[Based on ISO standard TS 25237.]

While the concepts of anonymization and pseudonymization is complex and few companies disclose how they achieve full anonymization, organizations must take appropriate measures to avoid data re-identification. This requires monitoring of anonymization requirements and analyzing the risks of re-identification prior to the implementation of a particular anonymization technique, including information correlation across multiple datasets. A trusted third party can be an organizational solution for pseudonymization, thereby de-coupling the identity data from the other personal data.

Data Sharing / Third-Party Management

Big Data concerns grow exponentially as the data is combined with additional datasets. Organizations maintain a responsibility toward their customers as they share data with third parties. Effective third-party management requires the inclusion of specific Big Data provisions within contractual agreements. Additionally, organizations should align Big Data with their overall strategy for the performance of third-party assessment and audits to ensure ongoing monitoring of third parties with a view to complying with data-sharing agreements.

Conclusion

Data abundance will become epidemic with all above-mentioned developments, and the billions of (Internet of Things) sensors will also bombard us with additional data, including personal data. The opportunities that (Big) Data Analytics present are too good to miss out on. Privacy is often an argument that is mentioned in a Big Data context, but for many it is unclear what Privacy regulations stipulate, how they relate to Big Data and what measures could be taken in order to use Big Data without creating Privacy risks or even Privacy breaches. As we have outlined, the different legal frameworks applicable to Big Data differ per region or country, but are converging in OECD countries. Ultimately, we have presented a universally applicable approach for using Big Data in a Privacy-compliant manner. The specific implementation should be based on a thorough Privacy Impact Assessment of the Big Data project. Big Data is here to stay and so is Privacy; the two can co-exist and even be married up – and thereby resolve the paradox in this article – by addressing Privacy aspects early on in the design phase of Big Data initiatives.

References

[ANP13] ANP, Meer dan 700.000 bezoekers in Amsterdam, 1 May 2013, http://www.nu.nl/binnenland/3411540/meer-dan-700000-bezoekers-in-amsterdam.html.

[Berk14] J. Berkvens & J. Prins, De bescherming van persoonsgegevens, Recht en Computer, nr. 4, 2014, p. 3.

[Cuij12] C.M.K.C. Cuijpers and P. Marcelis, Oprekking van het concept persoonsgegevens – beperking van privacybescherming?, Computerrecht, 2012 (13), pp. 339-351, https://pure.uvt.nl/ws/files/1477196/182_concept_persoonsgegeven_cc_1_.pdf

[EC12] European Commission, Commission Implementing Decision, 19 December 2012.

[EC14a] European Commission, Article 29 Data Protection Working Party, Opinion 05/2014 on Anonymisation Techniques, Brussels: WP29, 2014.

[EC14b] European Commission, Article 29 Data Protection Working Party, Opinion 06/2014 on legitimate interests, 2014, http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/wp217_en.pdf.

[EDPS15] European Data Protection Supervisor, Opinion 7/2015: Meeting the challenges of big data, 19 November 2015.

[GAO13] GAO, In-Car Location-Based Services: Companies Are Taking Steps to Protect Privacy, but Some Risks May Not Be Clear to Consumers, GAO-14-81: December 2013. http://www.gao.gov/products/GAO-14-81.

[Hale09] A. Halevy, P. Norvig and F. Pereira, The Unreasonable Effectiveness of Data, IEEE Intelligent Systems, vol. 24, no. 2, March/April 2009.

[Hill12] K. Hill, How Target Figured Out A Teen Girl Was Pregnant Before Her Father Did, Forbes, 16 February 2012, http://www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-was-pregnant-before-her-father-did.

[IAF14a] Information Accountability Foundation, A Unified Ethical Frame for Big Data Analysis, version 1, 2014, http://informationaccountability.org/wp-content/uploads/IAF-Unified-Ethical-Frame-v1-08-October-2014.pdf.

[IAF14b] Information Accountability Foundation, Big Data Ethics Initiative Part-B – Interrogation Framework, draft version, 2015, http://informationaccountability.org/wp-content/uploads/IAF-Big-Data-Ethics-Initiative-Draft-Part-B-Final-03-03-2015.pdf.

[ICO14] Information Commissioners Office, Big data and data protection, 2014, https://ico.org.uk/media/for-organisations/documents/1541/big-data-and-data-protection.pdf.

[ISAC13] ISACA, Big Data: Impacts & Benefits, ISACA White Paper, March 2013.

[ISO14] ISO/IEC JTC 1 Big Data Steering Group, Big Data: Preliminary Report 2014, 2014, http://www.iso.org/iso/big_data_report-jtc1.pdf.

[John12] J. Johnson, Big Data + Big Analytics = Big Opportunity, Financial Executive, July/August 2012.

[Klou15] S. Klous and N. Wielaard, Wij zijn Big Data: de toekomst van de informatiesamenleving, Business Contact, 2015.

[Koor11] R. Koorn & J. ter Hart, Privacy by Design: from Privacy Policy to Privacy-Enhancing Technologies, Compact 2011/0 (international edition)

[Koot12] M.R. Koot, Concept of k-anonymity in PhD thesis “Measuring and predicting anonymity”, 2012, http://dare.uva.nl/document/2/107610.

[KPMG13] KPMG, Big Data & Analytics: turning conceptual thinking into powerful results, KPMG Netherlands, 2013.

[KPMG14] KPMG, Going beyond the data: Achieving actionable insights with data and analytics, KPMG International, 2014.

[Maye13] V. Mayer-Schönberger and K. Cukier, Big Data: A revolution that will transform how we live, work, and think, Maven Publishing, 2013.

[Moer14] L. Moerel, Big Data Protection: How to Make the Draft EU Regulation on Data Protection, Tilburg University, 2014.

[Mont13] Y. de Montjoye, C. Hidalgo, M. Verleysen & V. Blondel, Unique in the Crowd: The Privacy Bounds, Scientific Reports, Volume 3, 2013.

[Priv11] Privacy Commisioner, Media release: Law Commission’s Package of Privacy reforms Would Build Trust and Certainty, August 2011, https://www.Privacy.org.nz/news-and-publications/statements-media-releases/media-release-law-commission-s-package-of-Privacy-reforms-would-build-trust-and-certainty/.

[Rich14] C. Rich, Privacy Laws in Africa and the Middle East, Privacy & Security Law report, April 2014.

[Rise14] T. Risen, FTC Investigates Target Data Breach, U.S. News & World Report, 26 March 2014, http://www.usnews.com/news/articles/2014/03/26/ftc-investigates-target-data-breach.

[SCTi14] SC Times, A year after Target data breach, aftershocks finally end, 25 November 2014, http://www.sctimes.com/story/money/2014/11/25/year-target-data-breach-aftershocks-finally-end/70080462.

[Stro15] C. Strong, Humanizing Big Data: Marketing at the Meeting of Data, Social Science and Consumer Insight, Kogan Page Ltd., 2015.

[Vier12] L. Viergever & J. Koëter, Is onze privacyregelgeving ‘Big data proof’? Tijdschrift voor Internetrecht, nr. 6, 2012.

[Whit14] White House, Report to the President: Big Data and Privacy: A Technological Perspective, May 2014, https://www.whitehouse.gov/sites/default/files/microsites/ostp/PCAST/pcast_big_data_and_Privacy_-_may_2014.pdf.

[Zwen13] G.J. Zwenne, Diluted Privacy Law, inaugural lecture to the office of Professor of Law and the Information Society at the University of Leiden, 12 April 2013, https://zwenneblog.weblog.leidenuniv.nl/files/2013/09/G-J.-Zwenne-Diluted-Privacy-Law-inaugural-lecture-Leiden-12-April-2013-ENG.pdf

Cyber in the audit

Iedereen die het nieuws volgt heeft recente cybercrime-activiteiten nog vers in het geheugen staan. Grote organisaties vallen ten prooi aan schijnbaar ongrijpbare criminelen die zich met technische trucs ongeautoriseerd toegang weten te verschaffen tot geld en intellectueel eigendom van organisaties. De daaruit voortvloeiende schade is van dusdanige proportie dat dit daadwerkelijk impact heeft op de bedrijfsvoering en de waarde van de organisatie en haar assets.

Voor de accountant is dit een essentieel risico om in kaart te brengen, alvorens een goedkeurende verklaring te geven over die financiële gegevens. Is de te auditen organisatie in staat een dergelijke cybercrime-aanval af te weren? Of is de organisatie eigenlijk al lang gehackt? Zijn de financiële gegevens dan nog wel betrouwbaar?

Inleiding

Medio februari 2015 wordt ontdekt dat cybercriminelen (de cyberbende Carbanak) gedurende een periode van ruim 2 jaar meer dan 100 banken in 30 landen gebruikten om omvangrijke fraude te plegen ([Kasp15]). De financiële impact wordt geschat op tussen de 300 en 400 miljoen dollar, maar men verwacht dat de totale schade uiteindelijk meer dan 1 miljard dollar zal bedragen. Doordat de cybercriminelen de controle hadden over interne systemen van een groot deel van deze banken, konden zij geld creëren door saldi van klanten (digitaal) te verhogen, om vervolgens het geld (digitaal of fysiek) weg te sluizen. Door kennis van IT te combineren met kennis van de relevante financiële processen en interne controle omzeilden de cybercriminelen betrekkelijk eenvoudig alle relevante beheers- en controlemaatregelen. Daardoor bleef deze fraude meer dan 2 jaar lang onopgemerkt – door zowel de organisatie als de controlerend accountant. Deze cybercriminaliteit werd uiteindelijk bij toeval ontdekt: een geldautomaat gaf op een willekeurig moment geld uit zonder dat iemand deze automaat gebruikte.

Figuur 1. Omvang Carbanak-hack ([Kasp15]). [Klik op de afbeelding voor een grotere afbeelding]

Figuur 2. Werkwijze Carbanak-hack ([Kasp15]). [Klik op de afbeelding voor een grotere afbeelding]

Dit voorbeeld maakt pijnlijk inzichtelijk dat de interne controle op onderdelen nog niet afdoende is meegegroeid met de veranderende dreigingen. Er is dus werk aan de winkel, ook voor de auditor. In dit artikel wordt ingegaan op de oorsprong en ontwikkelingen in IT-audit en op de vraag waarom cybercrime een verdere accentuering van de huidige auditaanpak vergt, mede aan de hand van enkele praktijkvoorbeelden. Tevens wordt een methodiek ten behoeve van een Cyber Maturity Assessment beschreven en wordt stilgestaan bij de impact van cybercrime op de financial audit. Hierbij worden ook handvatten voor de controlerend accountant en IT-auditor aangereikt. Ten slotte staan we stil bij de toegevoegde waarde van deze aanpak voor de cyberweerbaarheid van de organisatie zelf.

‘Cybercrime is here to stay’

Wat wordt nu precies bedoeld met cybercrime? Want inmiddels zijn hier veel meningen, ideeën en definities over gepubliceerd. In Nederland worden de termen computercriminaliteit, cybersecurity en vele andere termen veelal door elkaar gebruikt. Een definitie volgens de Kennisgroep Cybercrime van NOREA spreekt het meest aan: ‘Criminaliteit gepleegd via computers of netwerken’ ([Beus12]).

Uiteraard bestaan er velerlei soorten cybercrime en zijn hiertussen verschillen en overeenkomsten te identificeren. Kijk maar eens naar de termen cyberwar en cyberterrorisme. Cyberwar betreft veelal landen die een ander land op het vlak van internet of belangrijke nationale netwerken of infrastructuur (bijvoorbeeld SCADA[SCADA, Supervisory Control And Data Acquisition, is het verzamelen, doorsturen, verwerken en visualiseren van meet- en regelsignalen van verschillende machines in industriële systemen (bijvoorbeeld in olie-/gasindustrie).]-gerelateerd) onbereikbaar willen maken of zelfs beschadigen. Cyberterrorisme heeft meer betrekking op specifieke groepen die landen of organisaties willen ‘aanvallen’ vanuit hun ideologie.

De meeste mensen zullen bij cybercrime echter denken aan hacking, uitgevoerd door een individu met de intentie IT-systemen binnen te dringen om aldaar schade aan te brengen, om persoonlijk gewin te behalen of puur om in de publiciteit te komen. Het eerder vermelde cybercrimevoorbeeld van Carbanak staat niet op zichzelf. Al jarenlang is een stijgende trend waarneembaar, waarbij cyberincidenten zijn geëvolueerd van individuele ‘script kiddie’-acties tot professioneel georganiseerde misdaad (cybercrime). De motivatie achter deze incidenten is ook veranderd. Van oudsher waren dat status en aanzien (in de hackerswereld), maar vandaag de dag is er meer focus op financieel gewin, kennisvergaring (intellectuele eigendommen) en politieke invloed. Dit komt helder naar voren in cyberincidenten zoals bij Sony, Target, DigiNotar, NASDAQ, JPMorgan Chase, eBay en Home Depot. Enkele van deze voorbeelden worden verderop nog nader beschreven.

‘Cybercrime is here to stay.’ Dit wordt herkend en erkend door de toezichthouders, zoals de AFM, DNB en ACM, maar ook door organisaties als de NBA, PCAOB en ECB. Uit recent onderzoek van onder meer Verizon ([Veri15]) blijkt niet alleen dat de impact van cybercrime groot kan zijn, maar ook dat de kans van optreden aanzienlijk toeneemt. Op dit moment is het niet meer de vraag of er een cyberattack bij uw organisatie plaatsvindt, maar wanneer. En wellicht heeft deze aanval al plaatsgevonden, maar heeft uw organisatie dit nog niet gedetecteerd.

Concrete incidenten (zie ‘Enkele praktijkvoorbeelden’) tonen aan dat cybercrime een risico vormt voor organisaties. Maar cybercrime is ook een risico voor de accountants en hun reputatie. In het kader van de jaarrekeningcontrole kan cybercrime namelijk wel degelijk een significante impact hebben op de betrouwbaarheid van de financiële cijfers. Maar welke impact (en omvang) is dit precies? En wat moet de accountant en/of IT-auditor doen om de cybercrimedreiging voor zijn klanten en de aansprakelijkheid van de accountant zelf het hoofd te bieden? Om daar een goed antwoord op te kunnen geven is het belangrijk eerst de context van (cyber)security te beschrijven.

Oorsprong en ontwikkeling van IT-audit in financial audit

De oorsprong van IT-audit in de financial audit is te vinden in de toenemende automatiseringsgraad van administratieve processen. Doordat de gegevensverwerking in en rondom de financiële administratie niet meer handmatig maar met IT-systemen wordt uitgevoerd, is de accountant meer en meer aangewezen op het controleren van IT-systemen. Om toch voldoende zekerheid te verkrijgen dient een accountant aanvullend de betrouwbaarheid van de geautomatiseerde controlemaatregelen te controleren. Omdat kennis van financiële processen en interne controle alleen niet toereikend is om deze werkzaamheden uit te voeren, is IT-audit (voorheen EDP-audit) al bijna een halve eeuw een must ([Veth09]).

Een IT-audit wordt uitgevoerd om de betrouwbare inrichting en werking van zowel procesmatige als technische aspecten aangaande de geautomatiseerde gegevensverwerking te beoordelen. In het kader van de financial audit worden de IT General Controls (ITGC) beoordeeld. ITGC omvatten onderwerpen zoals de toegang van gebruikers tot programma’s en data, het monitoren van de IT-omgeving, het gecontroleerd laten verlopen van wijzigingen in het IT-landschap en het bestand zijn tegen beschikbaarheidsproblemen (bijvoorbeeld back-up en recovery). Een IT-auditor vormt zich daarmee een oordeel over het generieke stelsel van IT-beheersmaatregelen en kwaliteitsaspecten in en rondom de geautomatiseerde gegevensverwerking.

Door de toenemende complexiteit en verwevenheid van de te onderzoeken IT-omgeving en toenemende dreiging om misbruik te maken van kwetsbaarheden in die IT-omgeving, is het noodzakelijk om meer focus aan te brengen op cybersecurity. Dit om aanvullende zekerheid te krijgen over de betrouwbare werking van de beveiligingsmaatregelen ([Korn09]). Dit betreft het samenstel van preventieve, detectieve en repressieve beveiligingsmaatregelen in relatie tot processen, mensen en technologie.

Cybercriminelen maken veelal gebruik van (bekende) kwetsbaarheden in IT-systemen om de beoogde functiescheiding te doorbreken en zo bijvoorbeeld onrechtmatig gelden te onttrekken aan de organisatie. Dit vraagt om extra aandacht in de huidige auditaanpak.

Waarom vraagt cybercrime verdere accentuering van huidige auditaanpak?

Wat maakt cybercrime in het kader van de financial audit nu anders dan het beoordelen van de reguliere ITGC en waarom vraagt dit nu om een andere aanpak voor de auditor? Het antwoord is feitelijk simpel, als je de discussie niet al te academisch wilt maken.

Door vergaande ontwikkelingen zoals Internet of Things (IoT), self-service portals, mobile payments en social media speelt IT vrijwel overal een wezenlijke rol bij de bedrijfsvoering van middelgrote tot grote ondernemingen. In de reguliere (IT-)audit wordt veelal (terecht) gekeken naar opzet, bestaan en werking van de ITGC. Echter, deze beheersmaatregelen en de onderliggende processen zijn veelal gericht op preventie en maar beperkt op detectie. Met de enorme opkomst van de 7×24-uurs economie – met e-commerce, webshops en de vele bedrijven en overheidsinstanties – zijn deze maatregelen vaak niet toereikend. Er is namelijk sprake van een paradigmaverschuiving bij het inrichten van het stelsel van beheersmaatregelen en -processen.

Technologie en de bijbehorende bedreigingen lijken zich sneller te ontwikkelen dan dat organisaties adequate beheersmaatregelen kunnen inrichten. Hierbij is het besef gekomen dat men meer en meer moet accepteren dat cyberincidenten niet altijd te voorkomen zijn, maar dat men beter in staat moet zijn deze incidenten te detecteren en beter moet kunnen ingrijpen om de gevolgen te beperken (dus: meer repressieve maatregelen, grotere noodzaak tot detectie en repressie). Deze verschuiving van preventie naar detectie en respons vergt een nadere accentuering van de auditaanpak. Figuur 3 maakt inzichtelijk dat organisaties processen zoals Threat Management, Vulnerability Management en Incident Management moeten inrichten en uitvoeren. Deze processen zijn nodig om proactiever en tijdiger te kunnen reageren. De rol van de auditor is om de opzet, het bestaan en de werking van de Threat Management- en Vulnerability Management-processen ook te beoordelen.

Figuur 3. De verschuiving van reactieve naar proactieve maatregelen. [Klik op de afbeelding voor een grotere afbeelding]

Afhankelijkheid en kwetsbaarheidsanalyse met betrekking tot cyber

De accountant heeft tijdens zijn werkzaamheden op diverse momenten te maken met verschillende triggers die bepalend zijn voor de keuzes met betrekking tot (vervolg)stappen in de controleaanpak. De bestaande triggers kunnen hierbij worden uitgebreid met triggers aangaande cybersecurity. Afhankelijk van de antwoorden op deze ‘trigger’-vragen is het voor de accountant wel of niet noodzakelijk een gespecialiseerde IT-auditor of ethical hacker (verder) aan te haken. Bij voorkeur stelt de accountant gezamenlijk met de IT-auditor deze vragen aan de verantwoordelijke medewerker(s) uit de organisatie.

Dit zijn enkele voorbeelden van ‘trigger’-vragen die de accountant, in het gesprek met zijn klant, kan stellen om de afhankelijkheid en kwetsbaarheid met betrekking tot cyber in kaart te brengen:

Hoe schat men de cyberdreigingen en/of risico’s voor de organisatie zelf in? Welk belang hecht men aan vertrouwelijkheid en integriteit van de gegevens in de totale keten?
Levert of gebruikt men online services? Dit moet bezien worden vanuit de totale waardeketen (‘van zand tot klant’); een voorbeeld hiervan is dat HR-/payrolldiensten uit de cloud worden afgenomen of dat gebruik wordt gemaakt van externe asset brokers.
Heeft men bedrijfskritische applicaties die direct aan het internet gekoppeld zijn? Heeft men internetwebsites of -portals? Deze situatie is natuurlijk overduidelijk aanwezig bij internetwinkels en online banken, maar soms is dit ook minder goed herkenbaar, zoals bij slimme meters of vrachtwagenvolgsystemen.
Zijn er specifieke ‘kroonjuwelen’ die zeker goed beveiligd moeten zijn? Zijn er dreigingen op het gebied van bedrijfsspionage of diefstal van intellectueel eigendom? Of bestaan er risico’s ten aanzien van privacyovertredingen als gevolg van datalekken?
Kan een cyberaanval gericht op de organisatie of businesspartners (inclusief leveranciers) leiden tot discontinuïteit van de bedrijfsvoering en/of financiële verliezen (claims)? Denk hierbij bijvoorbeeld aan de situaties die ontstonden als gevolg van de problemen bij DigiNotar.
Zijn er recente beveiligingsincidenten geweest (die bijvoorbeeld via ORM gerapporteerd zijn)? Heeft men substantiële kosten moeten maken als gevolg van of ter voorkoming van beveiligingsincidenten?

Als op een of meer vragen een bevestigend antwoord wordt gegeven, is het noodzakelijk een verdiepingsslag op het gebied van cybersecurity c.q. cyberweerbaarheid te maken in de IT-auditaanpak. De invloed van cyber kan potentieel materieel zijn voor de financial audit. Het raakt ook het auditrisico van de controlerend accountant. Hoe zit het met de aansprakelijkheid en materialiteit? Zijn er door cyberincidenten of bestrijding van cybercrime wellicht onvoorziene financiële verplichtingen (boetes) of impairments? Hierbij kun je denken aan waardevermindering van het merk, kosten van herstel en respons of verlies van intellectueel eigendom met als gevolg dat de betreffende aandelen minder waard zijn geworden.

Enkele praktijkvoorbeelden

De (digitale) wereld is al diverse keren geconfronteerd met de gevolgen van cybercrime. Dit zijn een aantal spraakmakende voorbeelden van cybercrime uit de praktijk waarbij een organisatie van buitenaf gecompromitteerd is en interne kwetsbaarheden zijn uitgebuit:

Sony Pictures, 24 november 2014 ([Zett14]). Een hack door de groepering Guardian of Peace op diverse interne systemen van Sony waarbij zowel (persoonlijke) data van het personeel als kopieën van te releasen films zijn buitgemaakt. Deze zouden worden gepubliceerd als Sony niet zou afzien van de release van de film The Interview.
Target, november 2014 ([Rile13]). Target, een grote retailorganisatie, die eind 2013 een zeer groot datalek opliep van ruim 40 miljoen klant- en creditcardgegevens als gevolg van malware die op haar POS[Point Of Sale.]-terminal was geïnstalleerd. Dit heeft naast de vele negatieve publiciteit ook geleid tot een significant omzetverlies, diverse geldboetes, ontslag van een aantal bestuurders en verlies van gelden bij klanten van wie de gegevens waren misbruikt. Dit ondanks de implementatie van de nodige detectiemaatregelen, een Security Operating Center (SOC) en incident-management- en incident-responseprocessen. Maar helaas ging het bij de laatste twee fout doordat er weinig tot niets met de afgegeven signalen vanuit het SOC (in India) werd gedaan.
DigiNotar, augustus 2011 ([Netw11]). Iets dichter bij huis, in augustus 2011, wordt bekend dat de systemen van DigiNotar (eerder dat jaar overgenomen door Vasco) al sinds juni dat jaar zijn gecompromitteerd door Iraanse hackers, die daarmee in staat zijn geweest vervalste certificaten te genereren. Het gevolg: vele overheidsinstanties, publieke ondernemingen en burgers hebben een tijdlang geen transacties kunnen uitvoeren en zijn druk geweest de vele noodzakelijke reparatieacties door te voeren.

Welke rol had de auditor bij deze voorbeelden nu kunnen spelen? Het is aan de auditor om niet alleen zekerheid te verschaffen over de reguliere ITGC, maar ook over de cyberweerbaarheid van een organisatie. Dit vraagt een andere invalshoek voor de organisatie en de auditor dan zij tot nu toe gewend zijn. Het belang van een effectieve cyberweerbaarheid is natuurlijk groter naarmate de online presence en online diensten van de organisatie groter zijn. Dit geldt voor zowel de organisatie zelf als voor haar klanten.

De (IT-)auditor moet hierop inspelen door vast te stellen of cyber(security) in voldoende mate aandacht krijgt van de organisatie. In aanvulling op de eerder vermelde triggervragen moet de auditor zich richten op aspecten die hem/haar meer inzicht geven in de cyberweerbaarheid van de organisatie. Hiertoe kan de IT-auditor een Cyber Maturity Assessment uitvoeren.

Cyber Maturity Assessment

De Cyber Maturity Assessment (CMA)-methodiek is ontwikkeld om ook in het kader van de financial audit in te zetten. De CMA-methode richt zich op zes dimensies en maakt inzichtelijk wat de volwassenheid is binnen een organisatie ten aanzien van cyberweerbaarheid. De zes dimensies zijn:

1. Leadership & Governance

In dit onderdeel wordt gekeken naar de tone-at-the-top: is het executive management zich bewust welke risico’s de organisatie loopt op het vlak van IT en staat cybersecurity specifiek op de agenda om periodiek te bespreken en te kijken naar het veranderende bedreigingenlandschap en de potentiële impact op de organisatie? En stelt het management in voldoende mate vast of de huidige maatregelen nog voldoende volwassen zijn ten opzichte van de in kaart gebrachte bedreigingen?

2. Human Factors

Bij dit aspect wordt beoordeeld wat de organisatie specifiek onderneemt op het vlak van cyberawareness en opleiding van het personeel. Enerzijds om het personeel bewust te maken van de toenemende risico’s en anderzijds om zorg te dragen dat het personeel (inclusief beheerders) in voldoende mate getraind en opgeleid is om de cyberbedreigingen te herkennen, maatregelen te implementeren om de bedreigingen tegen te gaan dan wel tijdig te kunnen acteren als het daadwerkelijk misgaat (capabilities).

3. Information Risk Management

De second line of defence (onder andere de afdelingen business control en risk management) moet zorg dragen voor het tijdig delen van informatie omtrent voorgedane incidenten of ‘near misses’. Daarnaast zullen zij moeten meedenken in het opzetten van de incident- en responsprocessen en deze periodiek moeten bekijken of deze nog effectief zijn op basis van de incidenten dan wel scenario’s. Tevens kunnen zij zorgen dat cybersecurity van meet af aan in de business- dan wel IT-strategie en securityarchitectuur wordt verankerd (‘security by design’). Kortom, wordt er proactief gedacht en gehandeld met betrekking tot cyber?

4. Business Continuity Management & Crisis Management

De invloed van cyber op de huidige business-continuity- en disaster-recoveryplannen is enorm, wanneer alle denkbare cyberscenario’s niet eerder zijn bekeken en ingevuld. Wat als een Active Directory van een organisatie is gecompromitteerd? Denkt de organisatie dan te kunnen terugvallen op de reguliere recoverysite? Daar staat immers een goede kopie, back-up of in sommige gevallen een online replicatie van diezelfde Active Directory. Ook het hebben van op cyberscenario’s gebaseerde crisismanagementprocessen en -protocollen is essentieel, want vaak is snelheid en openheid van communicatie vereist, als dit al niet verplicht is voor een specifieke sector.

5. Operations & Technology

Dit onderdeel heeft grotendeels betrekking op wat ook wel de hygiëne wordt genoemd. Zijn de huidige en reguliere IT-security- en fysieke securitymaatregelen en -processen volwassen en worden deze periodiek door het management getoetst op betrouwbare inrichting en effectieve werking? En indien er tekortkomingen zijn geconstateerd, worden deze dan binnen redelijke termijnen opgepakt en opgelost? Deze ITGC dienen te worden gezien als de minimale basis c.q. fundering voordat men over cyberweerbaarheid kan praten, zoals onderwerpen als Threat Intelligence en Vulnerability Management.

6. Legislation & Compliance

Hierbij gaat men na of de huidige risk en security governance duidelijk en op het gewenste volwassenheidsniveau is en de potentiële juridische dan wel financiële aansprakelijkheid in voldoende mate is onderkend en afgedekt. Met name de proactieve opstelling van risk management en de rest van de tweede line of defence moet bijdragen aan het tijdig signaleren van omissies of tekortkomingen teneinde het risico of de juridische exposure voor te blijven of, beter, te voorkomen.

Figuur 4. De zes dimensies van de Cyber Maturity Assessment. [Klik op de afbeelding voor een grotere afbeelding]

Impact van cybercrime op financial audit

In IT-systemen zijn diverse waarborgen (beheers- en controlemaatregelen) aangebracht om ervoor te zorgen dat de gebruikers alleen toegestane handelingen kunnen uitvoeren. Met name toegangsbeheer, functiescheiding en change management vormen hier het fundament voor. Juist dit fundament wordt door cybercriminelen omzeild: zij maken gebruik van zwakheden in de systemen en verschaffen zich zo ongeautoriseerd toegang (doorbreken van toegangsbeheer) en verhogen hun toegangsrechten buiten alle geautomatiseerde beheers- en controlemaatregelen om. Daarmee doorbreken zij de vereiste functiescheiding. Deze vormen van cybercrime kunnen de betrouwbaarheid van de financiële gegevens verlagen (lees ook: het risico op materiële fouten in de controle vergroten) zonder dat dit naar voren komt in een reguliere IT-audit of financial audit.

Welke impact heeft dit nu precies? Hiervoor is het belangrijk eerst te kijken naar welke actoren we in het kader van cybercrime onderkennen ([Herm14]):

georganiseerde misdaad (wereldwijd en moeilijk te traceren en te vervolgen);
overheden (cyberspionage en cyberwar);
hacktivists (geïnspireerd door ideologieën);
interne medewerkers (ontevredenheid over management- en/of organisatieveranderingen);
journalisten (gericht op journalistieke primeurs).

Deze actoren hebben hierbij veelal de volgende motivaties of drijfveren:

industriële spionage – betreffende intellectual property (bijvoorbeeld overheden en concurrenten);
financieel gewin (bijvoorbeeld insiders en/of cybercriminelen);
politiek gewin (bijvoorbeeld overheden, actiegroeperingen en journalisten);
toegang tot ketenpartner (de aangevallen organisatie is slechts ‘collatoral’);
verstoring van operationele processen (van script kiddies tot georganiseerde misdaad).

De onderstaande mogelijke gevolgen leiden tot potentiële financiële risico’s:

verstoringen van de bedrijfsvoering door onbeschikbaarheid van systemen;
verlies van klanten als gevolg van wereldkundig maken van een cyberattack of hack;
verlies of ontvreemden van geld of middelen;
represailles door toezichthouders of contractpartijen (bijvoorbeeld boetes of intrekken van licenties);
verlies van marktaandeel en concurrentiepositie door ontvreemding van intellectual property;

Voor de financial audit maakt dit in de basis niets uit. Zolang deze verliezen correct op de balans staan, kunnen de financiële cijfers nog steeds juist zijn. Hierbij wordt ervan uitgegaan dat deze verliezen ook tijdig (binnen de auditperiode) worden gedetecteerd door de organisatie en/of accountant. Echter, het niet of niet tijdig detecteren van cyberincidenten kan leiden tot continuïteitsrisico’s voor de organisatie en een auditrisico voor de betreffende auditor (zie onder). Het IT-domein van een organisatie is tegenwoordig dermate complex en ondoorzichtig dat de meeste organisaties moeite hebben hackers buiten de deur te houden. In de praktijk blijkt het tevens lastig om te detecteren of en wanneer er sprake is van een inbraak door cybercriminelen en te bepalen wat hun motivatie is, in welke mate digitale gegevens zijn gemanipuleerd en wat de impact op de bedrijfsvoering en de financiële verslaglegging is.

De Nederlandse Beroepsorganisatie van Accountants (NBA) heeft eind 2014 in haar publieke managementletter voor banken ‘Van stabiliteit naar vertrouwen’ ([NBA14]) ook aangegeven dat de dreigingen door cybercriminaliteit uitdrukkelijk moeten worden meegenomen in werkzaamheden van de auditor aangaande de betrouwbaarheid en continuïteit van de geautomatiseerde gegevensverwerking. Opgemerkt wordt dat cybersecurity niet alleen van belang is binnen de financiële of administratieve sectoren, maar dat cybersecurity ook zeker van belang is in bijvoorbeeld de industriële sector. Voor meer informatie verwijzen we naar het artikel van Heil, Hogenboom, Waalewijn en Sprengers elders in deze Compact ([Heil15]).

Het is essentieel te beseffen dat hackers die bij een organisatie hebben ingebroken, vaak direct veel invloed kunnen uitoefenen op het functioneren van de IT-omgeving. Deze IT-omgeving is tegenwoordig vaak opgebouwd uit virtuele systemen – systemen die dus niet fysiek in een datacentrum staan. Het laat zich raden of en hoe organisaties hun IT-omgeving tijdig weer op orde krijgen zonder dat ze ondertussen in financiële en/of operationele problemen komen. Daarom is het noodzakelijk feiten te verzamelen over de werking van de cyberweerbaarheid van de organisatie.

Dreigingen met betrekking tot cyber introduceren de volgende mogelijke risico’s voor de financial audit:

financial misstatement: verkeerde weergave van de financiële cijfers (‘onder de motorkap’ ontvreemd geld);
assets die minder waard blijken of zijn geworden (gestolen of gelekt intellectual property);
onverwachte boetes van toezichthouders (DNB, AFM, ACM, CBP, ECB, SEC, etc.);
out of business door majeure disruptie van de IT-omgeving.

Samenvattend is het dus belangrijk voor de financial auditor om antwoord te krijgen op de volgende twee vragen:

Heeft de organisatie voldoende maatregelen geïmplementeerd om cyberinbraken tijdig te kunnen detecteren en daarop te reageren? Door gebruik te maken van de eerder toegelichte Cyber Maturity Assessment kan dit worden vastgesteld.
Wat als de organisatie al gehackt is en de integriteit van financiële gegevens mogelijk in het geding is?

In de volgende paragrafen wordt verder ingegaan op wat de auditor moet doen wanneer blijkt dat een organisatie al gehackt is.

Wat als zich een hack heeft voorgedaan?

Met de wetenschap dat elke organisatie ooit geraakt gaat worden door een cyberhack is het, zoals eerder aangegeven, van belang dat een organisatie zich proactief richt op tijdige detectie en respons. Maar de auditaanpak moet ook voorzien in het scenario dat zich een hack of ernstig cyberincident heeft voorgedaan. Hoe moet de (financial) auditor hiermee omgaan? Welke zaken moeten dan zeker gecontroleerd zijn voordat een verklaring kan worden gegeven over de getrouwheid van de jaarcijfers? In het geval van een hack of een ernstig cyberincident moet de accountant ten minste de impact op de financial reporting inclusief openbaarmaking beoordelen, alsmede de impact op de interne controle.

De accountant dient hierbij samen met de IT-auditor de volgende zaken nader te onderzoeken om te bepalen of het risico op materiële fouten in de jaarrekening is vergroot:

Vaststellen waar de cybercriminelen zijn geweest in het IT-landschap. Welke componenten zijn (mogelijk) geraakt c.q. geïnfecteerd?
Zijn er bepaalde application controls die niet langer meer als effectief te beschouwen zijn? En zo ja, wat moet er aanvullend nog worden gecontroleerd? Of resteert alleen nog de mogelijkheid om voor de betreffende jaarrekeningposten gegevensgericht te werk te gaan? En in hoeverre zijn de betreffende gegevens nog betrouwbaar? Is er sprake van onrechtmatige onttrekking van gelden c.q. fraude?
Vaststellen in hoeverre intellectueel eigendom is ontvreemd of gelekt. Is er intellectueel eigendom gelekt, dan moet de potentiële waardevermindering in kaart worden gebracht. Dit kan op basis van het reviewen van het forensisch rapport en eventueel het volgen van de reactie van de markt of concurrenten.
Vaststellen in hoeverre contractuele verplichtingen zijn geschonden en of er boetes moeten worden betaald.
Materiële bedragen/zaken dienen te worden opgenomen in de jaarrekening en de managementletter.

Daarnaast kunnen organisaties te maken krijgen met aanzienlijke oplopende kosten en/of andere negatieve gevolgen. Hier volgen enkele voorbeelden:

Herstelkosten, als gevolg van de aansprakelijkheid voor gestolen activa of gegevens en/of het herstellen van veroorzaakte schade aan systemen, en eventuele extra uitgaven of prikkels om klanten of andere zakelijke partners na een cyberaanval te behouden en/of schadeloos te stellen.
Hogere kosten/uitgaven als gevolg van het verbeteren van de cyberweerbaarheid, zoals organisatorische veranderingen, de inzet van extra personeel, het inhuren van derden (deskundigen en adviseurs), het trainen van medewerkers en implementatie van detectie en response tooling.
Verloren inkomsten als gevolg van ongeoorloofd gebruik van informatie, verduistering van activa c.q. diefstal van assets of het niet kunnen behouden of niet kunnen aantrekken van klanten na een cyberaanval. In sommige gevallen kan dit een grote negatieve impact hebben op toekomstige kasstromen en liquiditeit van de onderneming. In extreme gevallen kan dit leiden tot een faillissement van de onderneming.
Kosten met betrekking tot juridische geschillen en/of boetes.
Reputatieschade die het vertrouwen van de klant of investeerder nadelig beïnvloedt, hetgeen ook impact kan hebben op goodwill, handelsmerk, patenten en immateriële activa.

Wellicht moeten eerder gemaakte aannames door de accountant opnieuw bekeken of herijkt worden en er zal ook zeker onderscheid moeten worden gemaakt in de aanpak en inventarisatie van de impact van een cyberaanval afhankelijk van de vraag of de cyberaanval wel of niet voor publicatiedatum van de jaarcijfers bekend c.q. ontdekt wordt.

Voor de toekomstige controlewerkzaamheden moeten onder andere de volgende zaken met de directie van de organisatie besproken worden:

Specifieke aspecten van de bedrijfsvoering die op basis van (interne en externe) threat-intelligence- en scenarioanalyses aanleiding geven tot verhoogde en/of materiële cyberrisico’s en mogelijk extra investeringen vergen om de cyberweerbaarheid te vergroten.
In het geval van uitbesteding van primaire businessprocessen dient te worden vastgesteld of er materiële cyberrisico’s bij derden liggen en in welke mate deze beheerst worden en door wie. Overwogen kan worden ‘the right to audit’ uit te oefenen bij de betreffende provider.
Het al dan niet afsluiten van een relevante (cyber)verzekering om de (financiële) gevolgschade te kunnen beperken.

Toegevoegde waarde van CMA voor de organisatie zelf

Over de toegevoegde waarde van de CMA-methodiek voor de organisatie zelf kunnen we kort en krachtig zijn: CMA maakt snel inzichtelijk op welke vlakken de volwassenheid van de cyberweerbaarheid (inclusief respons) verbeterd moet worden. Als de betreffende zwaktes goed worden opgepakt, zal dit zijn vruchten afwerpen bij een mogelijke volgende cyberaanval. Als directie of raad van bestuur krijgt men antwoorden op relevante vragen zoals deze ([Herm14]):

Hoe heeft mijn organisatie haar cyber risk appetite en -prioriteiten bepaald?
Hoe is mijn organisatie ingericht met betrekking tot cybersecurity?
Investeert mijn organisatie momenteel voldoende in cybersecurity? En krijg ik waar voor mijn geld? En hoe verhoudt dit zich tot mijn peers?
Hoe veilig en robuust is mijn organisatie momenteel? Wordt mijn organisatie nu meer of minder veilig?
Hoe worden risico’s met betrekking tot mijn leveranciers en andere ketenpartners beheerst?

De uitkomsten van de CMA geven de organisatie inzicht en verhogen het bewustzijn ten aanzien van cybersecurity. Op basis hiervan kunnen verbeteractiviteiten worden geïnitieerd, zowel in de lijnorganisatie als door middel van projecten. Daarnaast dient de organisatie ook periodiek de bouwstenen van haar cyberweerbaarheid te bekijken en/of herijken. Het moge duidelijk zijn dat de cybercriminelen niet stilzitten en dat zij continu bezig zijn om nieuwe manieren te vinden om individuen of organisaties succesvol te kunnen blijven aanvallen. Het fenomeen ‘continuous improvement’ is zeker van toepassing voor organisaties met betrekking tot cybersecurity. Want ook voor cybersecurity geldt dat het werk nooit af is, men moet altijd alert blijven en continu blijven verbeteren om de cybercriminelen zo min mogelijk vrij spel te geven en de schade zo veel mogelijk te beperken.

Conclusie

Dat cyber de wereld om ons heen heeft veranderd mag helder zijn. De paradigmaverschuiving met betrekking tot cyberweerbaarheid in combinatie met de razendsnelle groei van cybercrime betekent voor de auditor dat hij zijn auditaanpak op onderdelen zal moeten aanpassen om nog steeds de gewenste toegevoegde waarde te kunnen leveren aan zijn klanten en tevens zijn eigen auditrisico te kunnen dragen. Met de zojuist aangedragen handvatten en door samenwerking met cyberspecialisten en de klant is dit te bereiken.

Literatuur

[Beus12] R. van Beusekom en L. Kers, Cybercrime: Richting definitie, afbakening en positionering, NOREA, 5 maart 2012.

[Heil15] R. Heil, J. Hogenboom, D. Waalewijn en M.J. Sprengers, Auditor, kijk ook naar de industriële systemen!, Compact 2015/3.

[Herm14] J. Hermans, Cyber security, een onderwerp voor aan de bestuurstafel, Compact 2014/1.

[Kasp15] Kaspersky Lab, Carbanak Apt: The Great Bank Robbery, Version 2.1, February, 2015. (Zie ook www.dutchcowboys.nl/cybercrime/grootste-bankroof-cyberbende-carbanak-steelt-1-miljard-dollar-van-100-wereldwijde-financiele-instellingen.)

[Korn09] P. Kornelisse, M. van Veen en M. Smeets, IT-beveiligingstesten als onderdeel in IT-audits, Compact 2009/4.

[NBA14] Nederlandse Beroepsorganisatie van Accountants (NBA), Van stabilisatie naar vertrouwen, publieke managementletter voor banken, december 2014 (signaal 5).

[Netw11] Networking4all, Timeline omtrent de DigiNotar hack, 7 september 2011, http://www.networking4all.com/nl/ssl+certificaten/ssl+nieuws/timeline+omtrent+de+diginotar+hack/

[Rile13] M. Riley, B. Elgin, D. Lawrence and C. Matlack, Missed Alarms and 40 Million Stolten Credit Card Numbers: How Target Blew It, Bloomberg, March 13, 2014, www.bloomberg.com/bw/articles/2014-03-13/target-missed-alarms-in-epic-hack-of-credit-card-data.

[Veri15] Verizon, 2015 Data Breach Investigations Report, 2015, www.verizonenterprise.com/DBIR/2015.

[Veth09] E. Veth, Externe assurance-regels voor het interne IT-audit beroep, EDP-Auditor, nr. 3, 2009.

[Zett14] K. Zetter, Sony got hacked hard: what we know and don’t know so far, Wired, March 12, 2014, www.wired.com/2014/12/sony-hack-what-we-know/.

SAP Basis Security — the crown jewels exposed

Organizations today are exposed to new security risks due to the implementation of SAP systems. Research shows that across industries these risks have been insufficiently mitigated. In addition, knowledge and tools to exploit these weaknesses are becoming easily accessible. These developments threaten the availability, continuity and particularly the reliability of the SAP system. Various vulnerable components within the SAP landscape can be secured in a relatively easy manner. However, this requires a multi-disciplinary team with capabilities within the application and the infrastructural layer.

Introduction

In the past few decades the definition of the terms ‘segregation of duties’ and ‘security’ were blurred by IT Audit and security professionals. Many SAP professionals refer to SAP security as the processes around authentication, roles and authorization profiles. The prevailing opinion is that users should only be allowed to access those functions in the system that are specifically and exclusively part of their job responsibilities and domain. This method should prevent staff from harming the organization and its system. Several organizations have invested lots of energy and efforts into their authorization concepts, partly as a requirement of the Sarbanes-Oxley Act ([Vree06]). Implementation of a sound segregation of duties concept doesn’t ensure that vulnerabilities in other (technical) aspects, such as the SAP gateway, password hashes or default internet services are automatically mitigated.

SAP systems are becoming increasingly complex, partly due to the increase of SAP functionalities and products. Organizations are progressively implementing SAP systems in addition to the enterprise core component (ECC), unconsciously creating an expansion of access paths to confidential and valuable data: the organization’s crown jewels. Moreover, SAP embraces technologies such as Java, HTTP, SOAP, XML and open SQL. Consequently, this has resulted in the adoption of all the inherent security risks that accompany these technologies. A single vulnerability in just one of the SAP systems can potentially compromise the whole IT landscape ([Edmo11]). Organizations must immediately mitigate the vulnerabilities within SAP that have been discovered over the past few years, to protect SAP’s integrity, continuity and especially its reliability. This includes technical components such as the SAP gateway, SAP Application Server, SAP Message Server, Internet Communication Manager and SAP router, as well as hashing algorithms and various ports/services that are opened during an implementation (SAP Management Console). These subjects have been addressed in various SAP security notes.

In the sections below, we elaborate on a number of vulnerabilities within the SAP landscape that we have encountered. We start with the password encryption method of SAP NetWeaver. Following that, we will take a closer look into SAP systems that can be accessed through the internet. We will conclude with a description of the risks caused by the absence of SAP security notes. The security and integrity of SAP at the Basis level often requires keen attention. By this article, we call for renewed attention on these aspects.

Vulnerabilities

The password encryption method within SAP (hashes)

Within SAP, passwords are saved in the user master record table in an encrypted format. An important aspect of saving a password is the way it has been encrypted. The encryption method is also called the ‘hashing algorithm’. Hashes are irreversible encryptions that make it impossible to retrieve the original password. The hashing algorithm that is used within SAP has been modified several times over the past few years. This was provoked by shortcomings in former algorithms, which were revealed by security researchers. At the same time, password-cracking tools became increasingly effective when it came to guessing combinations of passwords, by using rainbow tables. Within a rainbow table, all possible passwords and accompanying hashes are pre-listed without the need of further calculations. Using this method, passwords can be retrieved or matched to the corresponding hash easily. Password cracking tools can be applied to assess the complexity of the passwords used.

An efficient method to secure passwords is the use of a so-called ‘salt’, by adding a random series of characters to the password before it is encrypted. This makes it more difficult for password-cracking tools to retrieve the password. Prior to the introduction of SAP NetWeaver 7.1 or SAP NetWeaver 7.0 with Enhancement Pack 2, the user name was added as default salt for password encryption, as shown in Figure 1.

C-2013-3-eng-Schouten-01

Figure 1. Hash function.

John the Ripper (JTR), a well-known password-cracking tool, contains a module for analyzing SAP passwords. On the internet, various tools are available to download the password hashes from the user table (USR02) and prepare them for JTR. The authors have learned by experience that approximately 5 percent of all passwords are retrieved by JTR within 60 minutes. Most likely, JTR will retrieve a user with unlimited access rights (SAP_ALL).

On 21 February 2009, SAP introduced a security patch[https://websmp230.sap-ag.de/sap/support/notes/991968] with a robust hashing algorithm using a random salt. However, passwords that employ this new method are by default saved within the old, vulnerable format, due to compatibility requirements by other (SAP) systems. Hence, this solution is ineffective against hackers, as a weak password hash is still available. Fortunately, SAP provided security parameters to prevent hashes from being saved in the older vulnerable format.[login/password_downwards_compatibility ] Unfortunately, this solution introduces new challenges regarding the system’s connectivity with older kernels (interfacing). As a mitigating measure, authorizations that provide access to the password hashes should be restricted as much as possible. This would restrict the opportunity to view and misuse the hashes to a minimum number of people.

Unintentional exposure on the internet

Potential vulnerabilities that are frequently overlooked are included within SAP’s Internet Communication Framework services. A growing number of organizations make their SAP systems available for connections with customers, suppliers, partners and their own staff ([Poly10]). The expansion of functionalities causes organizations to expose their traditional internal systems, which were partly designed in the era of the mainframe, externally to the internet. Search engine Shodan[http://www.shodanhq.com], for e.g., gives an impression of the number of SAP systems that can be accessed via the internet. Shodan is a search engine that can determine, among other things, which software is being used per website. For instance, when this article was being written (August 2013), 7.493 SAP systems were linked to the internet via the SAP ICM (Internet Communication Manager).

C-2013-3-eng-Schouten-02

Figure 2. SAP links on the internet.

The search results from Figure 2 provide an overview of various publicly accessible SAP NetWeaver Application Servers. The majority of the SAP systems (1,762) are located in the US, followed by Germany (1,007), Mexico (409) and India (350). Making SAP functionalities available via the internet provides many advantages to organizations, but at the same time this may expose them— however unintentionally —to risks associated with the internet. SAP systems are becoming more accessible targets for cyber criminals or hackers, partly due to the exposure of vulnerabilities and misconfigurations within the (historically internal phasing) SAP system. Inherent vulnerabilities from default internet services can be misused by hackers for a targeted cyber attack. An example of a SAP service employing the so-called ‘Internet Communication Manager’ is the Info (/sap/public/info) service (refer to Figure 3). Our previous search, in Shodan, revealed various SAP servers offering this service via the internet unintentionally, allowing confidential information about the operating system, the database version, IP addresses and the SAP system Identifier to become publicly accessible (information disclosure). The spectrum of vulnerabilities that can be accessed by hackers can thus be expanded to the underlying layers as well. In addition, the risk exists that hackers will misuse unknown vulnerabilities via so-called ‘zero day exploits’, or misuse services with saved credentials. It is imperative to identify the services that are being offered via the internet. Particularly services that are accessible to the public or that bring specific security risks should be deactivated.[http://scn.sap.com/docs.DOC-17149]

C-2013-3-eng-Schouten-03

Figure 3. Internet-enabled services (/sap/public/info).

SAP security notes

Since 2008, the number of security patches – also called ‘security notes’ – launched by SAP has increased dramatically. Prior to 2008, SAP released only a few patches; but in 2010, 2011 and 2012 an average of 735 security patches were developed each year. Apart from the increase in quantity, the diversity of the discovered vulnerabilities has also grown. This can be explained by the addition of multiple features, components and modules to the old-fashioned SAP R/3 system. Due to the increasing complexity and nature of the risks, protecting and auditing the current SAP system is becoming more time-consuming and requires extensive knowledge of the SAP system.

Figure 4. Examples of SAP security notes.

Note	Description
1097591	Security Scan and XSS Vulnerabilities
1394100	Security note: Access to RFC-enabled modules via SOAP
1141269	Security: XSS vulnerability in SAP GUI for HTML
1177437	Cross Side Scripting issue with Internet Sales
1428117	Security Note: Introducing WSDL security in Java AS 7.20
1415665	SQL injection in Solution Documentation Assistant
1418031	Potential Security Issues in SAP-solution Manager
1445998	Disabling invoker servlet in the portal
1580017	Code injection vulnerability in TH_GREP

The growing addition of functionalities exposes SAP to inherent vulnerabilities in the underlying technologies. Examples of these adopted technologies include Java, HTTP, SOAP/ XML and open SQL programming languages. This expansion caused an extension of the quantity and diversity of security notes. Figure 4 contains an overview of vulnerabilities in different SAP systems (Solution Manager, Portal) and vulnerabilities inherent in the technologies used, via Cross Site Scripting and SQL injection. Unfortunately, not all organizations are in a position to implement security notes at short notice. The continuity of the SAP system must be guaranteed before implementing a security note. Partly due to the change management process, which involves a variety of acceptance tests, it often takes months for the vulnerabilities to be actually rectified ([Scho13]). Currently, SAP releases security notes on a monthly basis.

The risk description/exposure addressed by SAP within the note’s descriptions is often ‘high level’ and (perhaps) deliberately vague. The screenshots in Figure 5 outline the risk exposure in case security patches are not timely implemented within the SAP system. As demonstrated, malicious users are able to run commands at an operating-system level, as SAP does not validate the accuracy of the user’s input.

C-2013-3-eng-Schouten-05

Figure 5. Exploiting security notes 1580017 and 1445998.

To perform a risk assessment, organizations have to rely on the categories used by SAP to classify its patches. Among all the security patches launched for each category, we observe a peak, – particularly in 2010/11 – in the number of ‘hotnews’ patches that were launched. One of the causes for this peak is the attention SAP received within the security community. As of 2010, the number of SAP security conferences grew substantially, for e.g., during Blackhat and Hack in the Box ([Poly12]).

Figure 6 presents the development of different security notes that were launched. As yet, there seem to be considerably fewer patches released by SAP in 2013. On the other hand, vulnerabilities are much more serious in 2013 than in the previous years.

C-2013-3-eng-Schouten-06

Figure 6. Released SAP security notes.

One of the risks identified in different SAP patches concerns vulnerabilities in the SAP gateway (notes 1408081, 1465129, 1531820). The SAP gateway is a technical SAP component, which is deployed as ready to use. This means that security can be added afterwards, but is not activated by default. Technically, this involves the configuration of the SAP gateway by means of an Access Control List (ACL). The SAP gateway should exclusively communicate with systems within the ACL. If no Access Control has been activated for the SAP gateway, unauthorized persons or systems may access the SAP system, for e.g., by giving operating-system commands. Thus, a default SAP system is deployed from a usability rather than a security perspective.

A current trend within the security community is the adoption of SAP exploits within tooling. For instance, popular penetrating-testing suites, such as Metasploit, Bizploit and Onapsis X1 demonstrate how a SAP system can be targeted easily by a large number of (ignorant) people. Figure 7 shows plug-ins such as ‘callback’, ‘eviltwin’ and ‘gwmon’, which can be used to exploit misconfigurations in the SAP gateway. This results in a complete compromise of the SAP landscape.

C-2013-3-eng-Schouten-07

Figure 7. SAP penetration-testing suites.

Study of SAP vulnerabilities

Various aspects of SAP security issues were outlined in the previous section. To understand the extent and significance of these problems, various issues have been validated in actual practice ([Scho13]). Password hashes, internet services, security notes and scoping issues, among other things, have been addressed during research. This way, the extent to which SAP-related risks are being mitigated by organizations, is made explicit.

All members of the Security Access Management focus group within the VNSG (Association of Dutch-speaking SAP Users) were approached for this study. On 19 September 2012, a security issue questionnaire was submitted to this group. It comprised 21 different questions and was returned by 22 respondents.

The most vital results elaborated in the first three sections are listed below followed by the remaining results.

1. Use of weak password hashes

Unfortunately, we have found that many of our clients utilize a weak password hashing algorithm (such as A, B, D, E, F, G), even though powerful encryption methods exist and have been made available by SAP (such as H/I). This is caused by downward compatibility, on the one hand, and by the number of users that have been defined as ‘service’ or ‘communication’ users. These users do not have to comply with the password policy within SAP, and probably their passwords have never been changed afterwards. Only one of the respondents indicated that password complexity was being checked by means of password-cracking tools.

2. Internet services

The study has shown that of the total respondents, 41 percent deactivated the ICF[ICF = Internet Communication Framework ] services. Other respondents indicated that ICF services were not deactivated, or indicated that they did not have knowledge about whether the services were enabled or not.

3. Missing SAP security patches

Various security-related incidents and risks can be mitigated by the timely implementation of security patches in SAP. The investigation showed that less than 14 percent of the respondents implemented a security note within one month. Deficient security patches often expose an organization temporarily to all risks outlined in the patch. Unfortunately, a clear risk description/exposure is often not included within the security note, which makes it difficult for organizations to properly assess the risks. The study also showed that access to the SAP gateway was limited for 23 percent of the respondents. This observation is also recognized by many of our clients.

Other findings are:

4. Privilege escalation SAP and OSI

During an IT audit, the Operating System (OS) and Database (DB) layers are usually assessed separately from the application layer. SAP, however, offers the possibility to execute commands on the OS or DB layers directly from the user interface. This enables all SAP users to access other layers within the OSI model (Open Systems Interconnect), namely, OS and DB; although this access may not be mandatory based on the user’s work domain. By approaching the OS via SAP, the user can alter the database, bypassing all configured (application) controls within SAP. The risk exists that bank account numbers will be changed intentionally. It is essential, therefore, that ordinary users of the SAP application should have restricted access to the OS/DB level. At the same time, SAP access to the OS and DB should be limited. Research ([Scho13]) has shown that, as a rule, situations such as those described above are not examined during a SAP audit. As a consequence, the organization runs the risk of unauthorized changes being implemented in SAP that cannot be traced back to an individual.

5. Inadequate examination of non-production environments

A SAP landscape involves more than just a production system. As a rule, organizations use DTAP street with separate systems for development, test, acceptance and production. Each of these systems has several clients. From the user’s point of view, a client is a separate environment with a user name and separate transactional- and master data. In general, eight to 16 SAP clients can be found within a SAP landscape. In this context, we are only referring to the core component, SAP ECC, leaving aside other products such as CRM or BW. During an IT audit, usually one client (Production) is examined, instead of the entire landscape, despite other systems such as development or acceptance jeopardize the SAP security concept.

The risk exists that unauthorized users from non-production systems or clients logon to the production client by using Remote Function Call (RFC) or client independent transactions. These transactions create the opportunity to access the production client from other systems or clients. In the case of an incoming RFC connection, SAP relies on the authentication and authorization of the other (remote) system. Research ([Scho13]) has shown that IT audits tend to focus primarily on the production client and less on the many other clients or systems in the SAP landscape. It is essential that all systems and clients are examined together and in the same way, due to the interconnected nature of those systems.

Remediation plan

In the previous sections we have explained the issues related to SAP security. We initiated by outlining a number of inherent vulnerabilities in the SAP landscape. Subsequent to that, we examined the extent to which these and other vulnerabilities are mitigated in practice. Below, we have listed several practical solutions and guidelines for system owners to mitigate various SAP security risks. For practical and technical solutions refer to the Appendix at the end of the article.

C-2013-3-eng-Schouten-09

Figure 8. Remediation plan for SAP security risks.

Password hashes

First and foremost, the use of weak password hashes in SAP must be avoided as much as possible. SAP passwords should be saved in the improved hashing algorithm (CODVN H/I). This can be realized with the help of a SAP NetWeaver upgrade (min. 7.1). In addition, powerful password encryption can be enforced through security parameters.

Weak passwords can be identified by using password-cracking tools, such as JTR. Background users in particular are often configured with passwords that might originate from the implementation date of SAP. These passwords need to be changed and measures should be taken to avoid such mistakes.

It is said that you are only as strong as your weakest link. This perfectly applies to the Segregation of duties in SAP and is as strong as the weakest password. Various tables and access paths to the password hashes must be restricted by means of authorizations. The possibilities for gaining access to the password hashes must be acknowledged, analyzed and restricted. Password hashes must be regarded as confidential.

Operating System and Database

Access to SAP via the Operating System must be strictly limited. Security baselines on OS and DB levels must be designed and implemented. Also, authorizations which allow the execution of OS-commands via SAP must be restricted.

Ensure that the SAP user at the OS level is not installed using either root or administrator privileges.

Technical SAP components

Technical SAP components should only be able to recognize those systems that are authorized or familiar within the landscape. This way, SAP can be protected against unknown and malicious interfering systems. By implementing Access Control Lists for the SAP router, Oracle, Application Servers and Message Servers, unknown malicious parties are excluded. In this context, SAP systems and servers that are operational should be made explicit, while ensuring that no addresses are overlooked.

SAP security notes

Implement the most recent security patches, particularly for the SAP gateway. In addition, the most recent Basis Support package and SAP kernel needs to be implemented. This can be downloaded from the SAP Marketplace. Review Earlywatch/RSECNOTE reports for new patches on a regular basis.

RFC connections and interfaces

Investigate all RFC connections from non-production environments and verify the logon & security sections of these connections to prevent, among other things, the remote logon possibility

Services

Activate only those services that are essential to the business. Internet services surplus to requirements should be deactivated on the application server wherever possible. If possible, access to critical logfiles within the SAP Management Console should be restricted. The extent to which activities are logged should be decreased (trace level).

The recommendations outlined above can be used as a guide to mitigate various recognized SAP security issues. However, we do not warrant the completeness of the discussed SAP security topics. Other factors that could adversely affect the security of the SAP system include compromised ABAP source code, historical SOD’s, table debugging, network sniffing and many others. Also, it should be kept in mind that features such as soft controls and user awareness are preconditions for a secure system. The use of SAP penetration testing software should be considered to expose major SAP vulnerabilities. There are various commercial (ESNC) and easy-to-use freeware solutions (such as Bizploit) available on the internet.

Conclusion

Due to the expanse of SAP functionalities and products, organizations are inadvertently increasing the number of access paths to their crown jewels. In addition, SAP embraces technologies such as Java, HTTP, SOAP, XML and open SQL, which exposes SAP to all the security risks inherent to these technologies. The risks involved with the technical security of SAP on the Basis layer, are generally unknown and neglected. Research has shown that, consequently, these risks are only mitigated to a limited degree.

SAP security issues are noticed within the cyber security community. Since 2010, a growing number of SAP security conferences have been organized. Tools to exploit vulnerabilities in SAP have become easy to use and are accessible to a large number of people. Hence, exploiting a SAP system has become easier by the day.

In this article we have addressed risks, vulnerabilities and misconfigurations within SAP. Organizations are often unaware of the risks that they are exposed to by not fixing the neglected vulnerabilities. Fortunately, SAP is increasingly raising the quality of the default security measures in its system.

The effect on the regular IT audit is that working programs for SAP need to be adjusted and the risk analysis has to be revised. A number of the current vulnerabilities within the SAP landscape can be resolved in a relatively easy manner, as indicated in the section entitled ‘Remediation plan’. However, this requires a team possessing knowledge of the application layer and the infrastructure layer.

Appendix

The technical details listed below can be used as a guideline to mitigate a number of known SAP security issues. The numbers correspond with those in the ‘Remediation plan’ section.

1.	Parameter login/password_hash_algorithm & login/password_downwards_compatibility
2.	John –format=sapB hashfile
3.	Relevant objects:	S_TABU_DIS, S_TABU_NAM
	Relevant tables:	USR02, USH02, USRPWDHISTORY
	Relevant authorization group:	SC, SPWD
	Relevant transactions:	SE16, SE16N, SM49, SM69, DB02, SM30, SM31, N, UASE16N, SE17,CAC_DET_ACCAS_30, CX0A7, CX0A8, KCS5, KEP6, PRP_UNIT
	Relevant programs:	RK_SE16N, UA_SE16N_START
	Monitoring deletion of logfiles:	RKSE16N_CD_SHOW_DELETE, RSTBPDEL, RSLDARCH02
4.	Relevant objects:	S_LOG_COM en S_DEVELOP
	Relevant transactions:	SM49, SM69 (do not allow additional parameters)
5.	N/A
6.	Oracle – SAP:	tcp.validnode_checking = yes
		tcp.invited_nodes = (locahost, payrolldb, host3)
	SAP Gateway:	<> USER=* HOST=* TP=*
	SAP Message Server:	<> HOST=*
	Implicit deny	D * * *
	Incorrect entry	P * * *
7.	Earlywatch / RSECNOTE
	Remote OS authentication for the Oracle database instance (sapnote_0000157499, 21/10/2011)
	SAP management console (sapnote_00001439348, 14/12/2010)
8.	Relevant transactions:	SM59, SA38 – RSRFCCHK
9.	Relevant transactions:	SICF
	Activated services:	http://127.0.0.1:8001/sap/bc/gui/sap/its/webgui
		http://127.0.0.1:8001/sap/public/info
	SAP Management Console:	http://<host>:5<instance>13

References

[Edmo11] M. Edmonds (2011), SAP-Security Audit: The City Should Implement Additional Measures to Effectively Secure Its SAP Enterprise Resource Planning System, Audit Report.

[Poly10] A. Polyakov (2010), SAP-security: Attacking SAP Users, Digital Security Research Group.

[Poly12] A. Polyakov, Tyurin (2012), SAP-Security in Figures; A Global Survey 2007–2011, ERPScan.

[Scho13] T. Schouten (2013), A False Sense of Security; Auditing (Beyond) the SAP Production System, University of Amsterdam.

[Vree06] A. Vreeke and D. Hallemeesch, “Zoveel functiescheidingsconflicten in SAP – dat kan nooit, en waarom is dat eigenlijk een risico? De complexiteit van het SAP R/3-autorisatieconcept vervolgd” (“So Many Issues Connected with Division of Responsibilities in SAP – That’s Impossible, and Why Is That a Risk Anyway? The Complexity of the SAP R/3 Authorization Concept Continued”), Compact 2006/.

The 2020 Vision of Information Risk Management

This article briefly surveys the history of business information risks, from early risks to business continuity to increasingly severe cyber attacks. Over the years, the Information Risk Management landscape has changed, and managing it has become more complex. Still, the Risk Management function hasn’t changed that much. Looking ahead to 2020 we can imagine an ideal Information Risk Management process being in place, characterized by a number of key capabilities. Those capabilities would include real-time reporting and dynamic controls to monitor multiple factors, as well as flexible mechanisms to respond to higher or lower levels of risk. These features will need to be in place for businesses to perform effective Information Risk Management in the years ahead.

Introduction

Throughout the years, Information Risk Management has identified risks associated with the IT environment. Risks have evolved with changes to that IT environment. In the ’70s and ’80s, computers were entering the work space, and they were centralized and well managed. They were large mainframes, water cooled, taking up valuable space the size of a large office, but with less power than today’s average calculator. Risk Management was focused on business continuity issues, which were mitigated by backup and recovery functions. In the beginning of the ’80s new risks emerged as “high-powered” PC’s were entering the market. Computing power moved out of the central computer room into the private working space of employees. Although the first network communications were slow, and were only enabled when needed, the current IT environment demands always-on, all-encompassing network connectivity. Businesses have been moving in parallel with these changes, becoming increasingly dependent upon the availability of PC’s, servers, network connectivity, large storage capabilities, huge processing power, the internet and cloud computing. Data and information is the life blood of the business, and in some respects, is a company’s most important asset. Imagine if all the information that is used to steer an organization were suddenly lost. In a manufacturing context, production lines would grind to a halt, distribution would lose all direction, and managing accounts would become a real challenge.

Although IT has changed dramatically, Risk Management in essence is still the same as always. The complexities in IT are much more difficult than they were in the ’70s. IT has grown from specialty to commodity, and threats are changing by the minute.

This article showcases how Information Risk Management can work, and what Information Risk Management can bring to a company. It also describes the key capabilities that are needed to realize the benefits in common practice. The best Information Risk Management is not created overnight, certainly not in large and complex companies. Therefore we call this the 2020 Vision of Information Risk Management.

The Working Environment of an Information Risk Manager in 2020

Today most Information Risk Managers perform tedious risk processes, either on the input side or on the output side. On the input side, it is very difficult to definitively assess risk level. “Definitively” in this context means based on measureable risk factors instead of high-level assessments like: “The risk is about the same as last year, I think nothing has changed.” On the output side, there are issues in reporting on risk, starting with collecting the requisite data to provide a clear overview to business management regarding the risks the organization is facing. Furthermore, it is very difficult to link the information risks to business risks. In most large organizations all the mentioned risk activities (input, processing, output) take up enormous amounts of energy, without producing a definitive risk overview.

In drawing this picture of today’s Information Risk Management, we want to envision an ideal situation in the Information Risk Management of tomorrow. There certainly is a need to move toward better Information Risk Management, which today is insufficiently aligned with the current environment. Today’s environment is a hyper-connected world in which managing your own network is not enough. It is also an environment that is much more dynamic than it was twenty years ago: new threats might emerge tomorrow or next week, threats for which we have no planned response. Today, your risk process has to be agile.

If an Information Risk Manager in 2020 had “carte blanche” to design the organization’s IRM-world, what would it look like? Let’s select a couple of items for a “wish list,” and have a look at how they could contribute to risk management in 2020.

Single view of risk

First of all, the 2020 risk manager would have a single view of risk. This means that there would only be one place to find all the necessary data for reporting on Information Risk. This single resource would include information about all assets: from infrastructure assets such as routers, to business software and the business processes. Also, this single resource would contain information on risk factors related to joint ventures or third-party service providers, since they all impact risk levels.

Real time

Taking the concept of an optimum resource for assessing risk a step further, there would not only be a single place to find data about risk, but also the ability to view it in real time. With one push of the button, the Information Risk Manager could obtain a current overview of risk levels. No more ad hoc questionnaires or workshop assessments; no more chasing non-responders for their assessment of the current status. Data is fed into the system, either by automated scanning or by specialized staff, and is evaluated in real time for increased levels of threat, impact or vulnerability.

Dynamic reporting

This real-time view would also provide more detailed information, on demand. Although high-level management would normally be interested in the company overview, there might be reasons for them to drill down. For example, if an alert were triggered, management might want a report on the situation: it might be the local IT infrastructure, or it might be the core-ERP system. This could be a very powerful tool for the Risk Manager, based on data analytics and well-designed dashboards.

Department-specific views

In developing a single view on risk, it should be easy to create custom views for Finance, Sales, IT, but also for functions like CEO, COO, etc. In these views, risks will be displayed that are very specific to the department at hand. For example, the Sales department would see risks of disclosing cost and markup prices (not the risk of hacking, which is not a direct risk the sales department typically faces). The IT department would see risks of hacking, and so on.

Figure 1. A department-specific view. [Click on the image for a larger image]

Evolution of risks

With all this data on risk, there is just one more element needed to see risks over time: a time stamp. The Information Risk Manager of 2020 has the ability to zoom in on specific risks, organizational entities, or threat categories, and would be able to see how the risk levels have changed over time. The risk of hacking or cybercrime would emerge somewhere in the 80’s: popping up as a little dot, then growing to a serious threat over time. Another benefit of this is that it would be possible to extrapolate this view in order to predict the biggest threats. If linked to scenario modeling, it would be possible to identify the impact of possible future threats on the risks to IT and to the business.

C-2013-1-Hermans-02

Figure 2. Evolution of risks.

Risk based, linked with the business

The main objective of the IRM function is to continuously manage information risk and link it to business risk, with the sole purpose of determining the impact on business risk in order to provide dynamic, risk-based protection. In many large organizations Risk Management is limited to Compliance Management, i.e. reporting on the percentage of controls that are effective. However, business is crying out for insight into Risk! If controls fail, what does it mean for my business? The level of compliance as a figure on its own is not informative. In the 2020 vision, the risk manager is able to report on risk instead of compliance. More importantly, the risk manager is able to report on business risks, because threat categories in the IT-domain are linked to business processes.

Risk appetite

The risk manager of 2020 has an updated overview of risk appetite. The risk appetite is set by the business, as a measure of the level of risk the business is willing to take. When risk levels rise above the threshold of tolerance, action is taken to reduce the level of risk, either by initiating controls or by implementing additional measures on the level of the IT-infrastructure. Risk appetite is determined by modeling worst-case scenarios, which help the business imagine possible impacts. Risk managers can select and present control measures to the business, immediately showing the business what the effect of implementing them would be on the risk level. Both the effect on the risk level and the cost of the control measures is set out. In this way it is possible to find the optimum balance between risk reduction and increased cost levels.

Rationalized remediation

Since the IRM manager can pinpoint risks, and what the sources of the risks are, it is possible to remediate only in the areas where risks rise above accepted levels. In essence, it is not necessary to remediate compliance failures by default, just because a control has failed. Also, it might not be necessary to act on increased threat levels, as long as the risk levels remain below what is acceptable to the organization. Of course, spending money to remediate is not just based on compliance failures. It is also based on projections, emerging threats and so on. By extrapolating current trends, it is possible to make well-balanced investment decisions.

Overlooking the risk chain

In the hyper-connected world we live in, there is a need for looking beyond our own familiar boundaries. Depending on the relationship, partners in joint ventures and third-party suppliers can have a huge impact on a company’s data flows . A well-accepted risk level in our own organization might rise sky-high when security at a third-party data communications provider is found to be not up to specs. In the risk management processes of 2020, there should be a link with the risk management processes of our business partners. The same risk assessment processes would be used, making it easy to obtain risk levels from our vendors and link them to our risk levels. The drill-down capability mentioned earlier in “Dynamic reporting” could identify a specific vendor as the source of an increased risk.

Needed Structure and Key Capabilities for the IRM Function in 2020

In order to continuously manage and mitigate the information risks, the organization needs to be able to address these risks in a flexible and ongoing manner. This requires a central and overarching perspective on those risks that require management attention. An emerging threat landscape, a change in business activities, and a shift to using new technologies: these are all indicators that the risk landscape is changing. So far IRM methodologies and IRM models have not been able to capture this, in practice, in a dynamic way. For IRM practice to be able to provide a real-time and accurate view of the current risk environment would be the next step in the maturity of IRM.

The major elements in the 2020 vision are: a real-time view of actual IRM risks that provides senior management with insight into the risks that exceed the organization’s risk appetite and require attention. The risk view is an integral part of the business, and is aligned with enterprise risk management. IRM is able to assign resources to the risks that matter in an agile way, and is able to provide business opportunities.

Combining the earlier mentioned “wish list,” the IRM function of 2020 would look like Figure 3, outlining the required key capabilities. These key capabilities will be explained further in this article.

Figure 3. Key capabilities of IRM. [Click on the image for a larger image]

Key Capability 1: Integrated, standardized IRM processes, linked together by the Risk Register

In the center, we see the four core IRM risk processes, in effect:

Risk Assessment – the process of performing risk assessment;
Risk Treatment – the process of controls selection and implementation, or determining other treatment options, including risk acceptance or avoidance;
Compliance Monitoring – the process of control compliance monitoring;
Security Monitoring – the process of incident response and surveillance, threat and vulnerability management.

The four core IRM processes must be fully standardized across the organization. They must also be integrated via a Risk Register and by using automated processes to perform IRM with extensive workflow mechanisms. Integration also means that newly identified threats will feed the risk assessment process, making the risk register a dynamic system.

The IRM function ensures all information risks are monitored, identified and handled as part of regular business processes. The concept of a Risk Register plays a crucial role in this model: it acts as the heart of information risk management, where all risks are listed as they are input from the IRM processes, and where the strategy of managing relevant risks comes together. Based on the information in the Risk Register a real-time view of the risk status can be provided (both within the IRM function and also outside of the function) to stakeholders in the business and to IT management.

One important prerequisite is having a uniform approach to Risk Management throughout the entire organization. In large organizations there might be multiple IRM staff who all need to adopt the same methodology to achieve comparable risk results. Clear governance needs to be in place to enforce this.

Key Capability 2: Top-down, proactive Risk Management – determining the risk appetite

Linking to enterprise risk management

IRM must be part of the business context and must be fully aligned with business goals and needs. Only then will IRM be able to show its added value by providing insight into business opportunities and risks that should be avoided. To be able to show the added value of the IRM function, the IRM risks need to be mapped or linked to business risks (or “enterprise risk management”). This enables a top-down approach where IRM and ERM are aligned instead of existing in two separate worlds.

C-2013-1-Hermans-04

Figure 4. Alignment of IRM and ERM.

This brings us to another important prerequisite: asset management. Since there is an undeniable relationship between business processes, applications and infrastructure, it is necessary to define these relationships, so that risks on the infrastructure level can be linked to specific business processes. This is not going to be easy to accomplish.

Using worst-case business information scenario planning to determine the information risk appetite

In many organizations it is a common “Pavlovian response” to immediately start drafting and implementing controls when a risk is identified, without asking what level of risk is acceptable. These decisions are often made, although with all good intentions, by IRM professionals without consultation with the appropriate business representatives.

In the IRM 2020 world, business representatives will identify the level of risk they are willing to take (risk appetite), which allows for risk management in the most efficient and economical way possible.

This requires a sound and structured process to define the risk appetite of the business, by using the technique of worst-case business information scenario planning. This process must translate the risk appetite into discrete levels of acceptable risk, taking into account factors like changing business models, new and/or changing legal and regulatory requirements, as well as emerging IRM industry standards.

Key Capability 3: Bottom-up continuous compliance testing / monitoring

Compliance testing / monitoring is also an essential function of IRM 2020. Whether it is monitoring for specific regulatory requirements, for internal control, or for certification reasons, organizations are used to testing typical controls. In the world of IT auditing, the results of controls monitoring are binary: either the control is operating effectively or it is not. Knowing the results from controls monitoring helps managers verify and approve current protocols, and it also provides valuable insight into whether, in practice, risks are being effectively mitigated or not. Where control failures are identified, the risk is apparently not being effectively mitigated.

In the IRM 2020 world, we will have extensive and continuous compliance monitoring, using sophisticated tools. This continuous compliance monitoring will enable an organization to have nearly real-time view on the compliance level of IT assets. Of course, IT assets that require continuous monitoring will not be limited to those within the boundaries of the organization. Some IT assets will be outsourced to managed services providers or cloud providers, and some will be managed by the organization’s business partners.

Key Capability 4: Anticipating emerging threats

Threats – changes in the threat landscape affect risk levels

A hot topic in the media these days is cyber attacks. It is almost impossible not to have noticed the increase in external threats sometimes called cyber crime or even cyber warfare. Organizations should be careful of believing too readily in media hype, on the one hand; but on the other hand, they should not be blind to the fact that cyber-related threats are emerging.

These threats are a factor in determining risk levels, but the actual threat is difficult to assess with a mathematical accuracy. These threats are external, and it is difficult to estimate the threat level. There are, however, several sources that can determine changes in threat levels. Scientific reports on natural disasters, internal data on IT equipment theft, and cyber intelligence reports from governmental institutes are just a few examples of sources that can provide insight into the decrease or increase of a threat level. It is important to include a threat-management process in the IRM function, as an increase or decrease in the threat level might mean that an organization’s response is no longer appropriate (either too much or too little is being done to mitigate the threat).

Changes in threat levels often focus on cyber-related areas, such as hacking and espionage. Although this area is seeing the highest degree of change, it should not be forgotten that other threats are also subject to change. In the IRM 2020 model, threat intelligence is considered to include all areas of threat management.

Vulnerabilities – findings have impact on risk levels

In recent years the focus has been on identifying vulnerabilities in the IT environment, especially within the IT infrastructure. Ethical hackers identify numerous technical vulnerabilities in IT systems through performing penetration tests. In addition, automated tooling performs scanning activities with even more (negative) results. Apart from the obvious response (fix the vulnerabilities), these results should be assessed to determine whether these vulnerabilities affect the risks documented in the Risk Register.

This poses a challenge for the security professionals, as the identified vulnerabilities cannot be related one by one to specific risks. It is not uncommon that an ethical hacker or penetration test discovers several hundred vulnerabilities. Therefore it’s necessary to translate from individual vulnerabilities to categories of vulnerabilities on the level of risks. In this way discovering vulnerabilities leads to an increase in the risk level. As long as the adjusted risk level does not exceed the risk appetite level, no direct action is required.

There is a critical consideration that is easy to forget here. Performing penetration tests or other scanning activities results in discovering vulnerabilities in the selected areas, while other areas not subject to the test might appear to be safe. It is therefore important to be able to extrapolate the results of testing in one area to other areas, when there is sufficient similarity to support comparison. This might mean that a vulnerability category is adjusted over a range of assets, although not all these assets have been tested.

Incidents – analysis leads to understanding threats and vulnerabilities

As indicated by an ISF report in September 2012 (“You Could Be Next: Learning from incidents to improve resilience, ISF 2012”), incident response is an often overlooked area. The ISF report even states that Risk Management is incomplete without post-incident review. An information risk management incident is the exploitation of an existing vulnerability by a threat. Vague definitions, such as provided by ITIL (“Information security incidents are those events that can cause damage to confidentiality, integrity or availability of information or information processing”) do not help much. In practice a distinction is often made between an event of interest (EoI) and a security incident, where the EoI can, but not necessarily will, lead to an incident. Organizations are inclined to solve incidents as quickly as possible to be able to get back to normal operation. This is not surprising: the controls that have been implemented to mitigate the risk have failed, and the risk of an incident occurring has become reality. However, security incidents should be carefully analyzed for the underlying problem (also known as the root cause), as this might indicate a structural failure among controls, a general increase in vulnerabilities, or an increase in a threat. This information must be captured and incorporated into the central Risk Register to be able to determine changes in the risk posture.

Key Capability 5: Risk quantification to compile extensive risk dashboarding and steer to sustainable IRM investments

Small business environments might benefit from a qualitative approach where risks are categorized and described in a few paragraphs. Providing senior management with insight into the risk posture requires a risk manager to analyze the risks and aggregate them into a high-level report.

However, in large-scale IT environments with hundreds of applications, multiple networks and various sites, this approach would take months, and the aggregated report would consist of hundreds of pages.

To solve this, large organizations move from a purely qualitative risk management approach to a more quantified approach. This requires some more explanation. Risk Quantification as a financial instrument that provides exact, numerical values on impact and likelihood is a common method in the financial services industry. Insurance companies have a huge amount of historical data on the chance that an event will occur and the average cost of this occurrence. Depending on how much risk the company is willing to take, it can calculate the insurance fee that it will charge for its product. Due to the large volumes of data, these calculations have a relatively high degree of accuracy. Individual deviations will be relatively few and will be compensated for within the largely predictable insured population.

Regarding information risk management, this quantification is not supported by hard figures that make it possible to quantify risks. However, the IRM function needs a uniform method to quantify risk. If risk is defined as the result of Threat level, Vulnerability level and Impact level, then IRM needs a method to assign numbers to these levels. This will be one of the most challenging aspects of IRM in the coming years. To make it even more challenging, the levels constantly change, due to increased threat assessments, compliance failures, or newly discovered vulnerabilities or re-assessed impact levels.

The risk quantification, feeding the risk register, will also allow managers to steer towards sustainable IRM improvement programs. Based on the risks in the Risk Register, a project portfolio plan can be drafted to identify projects and programs that aim at improving the risk treatment in a sustainable way. With this intelligence, organizations can spend their resources on those risks that matter, resulting in a rationalized risk remediation.

Risk Management Fundamentals

Risk Management should, ideally, take inventory of threats and probabilities, producing an overview of the risks sorted from highest to lowest, so that the most invasive risks are handled first. It should monitor the mitigating controls and/or actions, in order to ensure that identified risks are correctly handled by the organization.
Risk = Threat × Vulnerability × Impact. There is no one single risk. Risk is always related to a threat. If there are 50 relevant threats (or threat categories) identified, this would result in 50 risks (the ISF standard of good practice (2012) identifies 39 Threat Categories).
For the initial set-up of a solid risk management process, this standard details the following stages:
- Context establishment: understanding the business environment you are operating in. This helps to value the impact of certain threats, were they to occur. It also helps you to identify the right threats in the first place.
- Risk assessment: identifying threats, estimating vulnerability and impact.
- Risk treatment: implementing measures to mitigate risk, to monitor, to plan, and to act.

Conclusion

Even though the IT landscape has changed dramatically since the ’60s and ’70s, IRM methodologies have not changed all that much. True, IRM processes have successfully identified new risks arising in our current environment, but the process and the tooling that is used to achieve this is largely unchanged . Accurate and timely insight into Risk Levels is still hard to achieve, but under the right circumstances it is definitely achievable.

This article mentioned the key capabilities that are needed to realize the potential of the 2020-IRM manager. Inspired by Martin Luther King’s famous speech “I have a dream,” we should be looking forward to these possibilities, instead of only running behind and fixing the disasters after the fact. In large organizations, it will be possible that the person who is ultimately accountable for risk management has a real-time overview of current risks, aggregated to a comprehensive level. Exceeding tolerable thresholds will automatically lead to alerts, where it will be possible to drill down to the harmed asset(s) or business entities and identify the localized problem. Designing new projects or programs will be facilitated by simulating threats or overruns, to better defend against malicious entities or spontaneous events.

Realizing these possibilities requires a structural approach, starting with embedding the key capabilities mentioned earlier and knowing where you are heading. By determining how far you are from the goal, you can design a program to go forward and attain that goal. As always, without change there is no progress.

References

ISF report September 2012: “You could be next, learning from incidents to improve resilience.”

ISO/IEC 27001:2005 Information security management systems.

ISO/IEC 27005:2011 Information security risk management.

The Standard of Good Practice for Information Security (ISF 2012).

Data security in an era of cybercrime: steering through feeling

IT security has always focused on the prevention of threats from hackers and internal fraud. However, something that we ought to have learned from previous incidents of publicized cybercrime, is the fact that one-hundred-per-cent security does not exist and, moreover, actual break-ins frequently remain undetected. Organizations should realize preventive controls as a precondition, and they should also have adequate controls for the detection of, and response to cybercrime.

Security begins with an awareness of the values that deserve to be protected, the recognition of threats, the definition of roles and responsibilities, and the determination of the required maturity of security processes. Then comes the configuration of a secure IT infrastructure. However, how can security be realized without the introduction of a surplus of measures?

Introduction

The world seemed simple prior to the advent of IT; physical security was the only area that potentially could be in danger. Organizations that had to deal with highly sensitive information made (limited) use of data classification and labeling (the marking of data classification on documents).

With the arrival of the first computers, security appeared to have become even simpler, in view of the fact that applications could only approach the data stored in centrally managed mainframes via previously defined functionalities and via strict procedures. Transactional data, in particular, was processed in this mainframe environment. The advent of the PC essentially altered the complexity of security. Users now created and processed data themselves in documents (files), and also dealt primarily with non-transactional data, which often included the highly sensitive data.

We have advanced quite a distance in the meantime. USB sticks are used for the exchange of data and, unfortunately, also for the transfer of viruses and trojans. Phishing occurs via e-mails, and users are enabled to install software on their own PC. End users store and even process documents in the cloud.

Also, with the advance of social media and a new – young – generation of users, combined with the deployment of private IT resources such as smartphones and tablets within one’s own organization, it is becoming increasingly unclear whether or not an adequate level of IT security has been or can be realized.

Therefore, it is time for reflection. Can we apply fewer hard controls and more soft ones? Which criteria have to be imposed on security, where should security be regulated in the technology to ensure transparency, and where should we be able to rely upon the security awareness on the part of end users, developers and managers? Rules for IT management have become increasingly extensive and complex. There are even more rules than the users, managers and developers know about. So, it is time to apply the modern principle of ‘steering through feeling’ to data security to a greater extent.

More steering through feeling and, with that, greater awareness, are required considering the impact that a positive culture (security consciousness) and governance (organization, roles and responsibilities) can have upon data security, resulting in adequate IT security processes and a secure IT infrastructure (see Figure 1).

C-2013-0-Kornelisse-01

Figure 1. Cause and effect.

This article will cover the following themes, analyzing whether or not it is possible to have more ‘steering through feeling’:

security awareness
classification and labeling
security measures in IT processes and IT infrastructure
demonstrability of security.

Security awareness

The regular stimulation of security awareness supports steering through feeling. In terms of security awareness, this means that organizations should pay more time and energy to this development, with the result that users and managers spontaneously deal with data in a better way.

Users themselves appear to be rather naïve: ‘Do users think seriously enough about the required IT level of security?’ A good example is the introduction of smartphones and tablets in organizations. These devices are usually brought into the organization by board members, and then this habit spreads to other users in the organization. Due to ease of use and trend sensitivity, the idea has arisen that organizations must be able to use such IT resources immediately. Risks are often (temporarily) accepted.

However, with the use of smartphones and tablets, people are not always aware of the value of the data that is stored and processed on these IT resources, or of the external and internal threats that may be involved.

In reflecting on the value of data, people often think of the value of data for the organization itself. However, it is becoming increasingly important to consider data in the ecosystem of collaborating organizations. Think of cybercrime in the public domain for example, where criminals seek data outside the organization under attack:

Diginotar was attacked in order to create digital certificates.
RSA was attacked to access SecurID authentication information.

In the past, much attention in security enforcement was devoted to the identification of threats. This tended to result in fear, doubt, and uncertainty. It seems, however, that it is more important for users to think about the values that they are working with, and the values that ought to be protected in that case. This requires training in security awareness – but such training is scarcely available. As a component of security awareness, attention should be paid to the assessment of values, the acknowledgement of generic security facilities, and the corresponding limitations of security facilities for IT resources.

As a part of the data lifecycle, users and managers should reinforce their awareness of how to deal with data security, so that they come to treat data and systems as if these involved their own wallets.

Create. Does a user reflect on the stakeholder to whom the data may be valuable, and on what the magnitude of this value may be? Can people assess, on the basis of the recognized value, who should have right of access to, or be able to process, the data? Is it clear which metadata is being created, or what the document properties are?
Store. Given the value of the data, is a user aware of where the data can be stored, and of whether or not the data ought to be encrypted (think of the use of facilities such as Dropbox, for example)?
Transport. Should a user encrypt his/her data for transport? Can the data be transported via e-mail or a USB stick?
Process. Can the data be processed in the cloud, should the user make specific agreements about this?
Sleep. Is it clear who the owner is of data when it is dormant?
Delete. Are the conditions of data retention known to the users? Is there some kind of guarantee covering the timely or perhaps premature deletion of data?

Classification and labeling

Highly sensitive data should be recognizable. Data that can be easily and intuitively classified, requires no explicit categorization or labeling to ensure careful treatment. That is self-evident. Accordingly, the formal classification and labeling of most data is unnecessary.

Recognition of classification

Only a few users are requested to classify data on the basis of the value of the data, if an organization classifies data at all. Organizations that actually do so mostly make use of a so-called CIA classification (Confidentiality, Integrity, Availability), directed toward applications rather than the data itself.

The classification of data can take place in many ways, and is generally experienced as being complex and difficult to maintain. That is why, in many cases, data classification simply does not occur, or occurs incorrectly or incompletely. As a consequence, no explicit labeling takes place either. This being the case, it is not always clear to third parties who is entitled to view the data, let alone know where data is stored and when the decision to delete it should be taken.

However, there is often a subconscious awareness of the sensitivity of data, which provides a basis through which the distribution of data can be limited.

It will be evident that public media such as Twitter, LinkedIn and Facebook are only intended for data that is allowed to enter the public domain. For data used within an organization, the allowed distribution is often much more complex. It is advisable to acknowledge as few data classes as possible, and to choose these classes in such a way that they are intuitive to the users and yet still function if the users do not spontaneously remember them. In a simple process we can think of a distinguishing (in-house) style that can be clearly recognized by internal members of staff. On the basis of the acknowledged value (what is important to the organization – think of Intellectual Property, what will be the damage if the data becomes public, etc?), the following classes can be deployed and can be spontaneously applied by users despite a lack of knowledge:

public (intended for clients and other interested parties)
internal (intended for all personnel, preferably not for external distribution)
confidential (intended for a small group of people outside of which the data may not be accessible)
personal (often intuitive, intended for one specific person, such as HR-specific information).

You should make differences in classification explicit, particularly in situations where the difference in classification is less pronounced. One example is the use of the ‘Internal’ and ‘Confidential’.

Types of data

In the classification of data, it is expected that structured and unstructured data are treated differently:

Structured data is processed by an application and is primarily labeled through classification via the processing application. This means that the application can automatically print a classification on reports. The payslips of the members of staff, upon which the label ‘Personal’ can be printed, is a good example of this.

An organization should ask itself explicitly if all relevant structured data is adequately shown. In the case of payslips, it is obvious that salary information is personal, and the data is indeed shown. However, data that does not seem to have the ‘Personal’ classification – but should nevertheless be regarded as private – is often stored in a structured way, via marketing websites for instance. In this context one can think of security incidents where the clients’ private information, such as e-mails and other data, was made public by hackers of marketing sites. Suddenly privacy-sensitive data was there for the taking. In this way, it became clear that the data ought to have been classified as ‘Personal’, and should have been assigned the appropriately strict security status.

Accordingly, it is advisable to first formulate an adequate overview of processed data for each application and to classify the data, and only then classify the application itself.

In view of the fact that structured data is managed for the users, it is advisable to actually classify it.
Unstructured data is less easy to define. For unstructured data, it is important that users have an awareness of the necessary degree of security with regard to the IT resources (laptops, tablets, smartphones) and central IT services (file servers and other shares) they use to store sensitive data. In this process, it must be clear who is allowed to store which data where and for how long.

In view of the fact that unstructured data is managed by the users themselves, the users should be encouraged to steer through feeling; in other words, the issue of classification should be spontaneously assessed at the selection of the IT services, such as e-mail, tablets and file servers.

Measures in IT processes and IT infrastructure

Security services should be realized with the greatest possible transparency, via generic IT services such as e-mail and tablets, which is what a user intuitively expects.

Security services should be directed toward measures for the prevention and detection of, and response to, threats from both outside and in.

In the configuration of security measures, it is advisable to start with the expectations of the end user, and with the value of the data with which the organization normally works. For example, a research department can cover highly sensitive data such as intellectual ownership, while a shop may be dealing with low-sensitive data such as product, price and sales information. Nevertheless, in dealing with data, an organization must be aware of the threats that are directed toward the organization, as well as indirect threats in cases where the organization is a part of a larger chain.

A simple process can consist of limiting necessary measures (not closing off USB ports, for example), and also of the consistent application of measures so that exceptions do not entail an enlargement of complexity (such as the standard configuration of laptops with encryption of harddisks and the use of personal firewalls).

A simple process to realize and maintain data security is shown in Figure 2. First, the necessary security measures are defined in line with an analysis of the risks. Then, on a compliance basis, it is determined whether or not these measures can be maintained. If that turns out not to be the case, any non-compliance is mitigated, explicitly, but in relation to the risk involved.

This security process for the realization of a safe IT service can be run through for both structured data and unstructured data.

With structured data, the sensitivity of the processing application is established, and the security measures are adapted to this.

However, with unstructured data, it is possible that there will be many IT services (IT resources and applications) processing and/or storing the data. In the case of unstructured data, the security process will not be run through for data but for generic IT services (such as the file server, smartphones and tablets, and internet storage services). Unstructured data (such as e-mail) can be read in this framework. Accordingly, with IT services such as these, the possibility to read the highest data classification should be the starting point. On the basis of this classification, the security measures can subsequently be selected. Depending on the sensitivity of the data, more rigorous security measures can be chosen, such as:

user name and password, or a second form of authentication such as a token
unencrypted storage on a secure server, or encrypted storage on the same secure server
standard tablet for the use of e-mail, or e-mail in a so-called ‘encrypted sandbox’ application.

Figure 2. Security process for data and systems. [Click on the image for a larger image]

The selection of security measures is easier said than done. Keep in mind that four regulation sections can be identified for every IT service (see Figure 3).

C-2013-0-Kornelisse-03

Figure 3. Regulation sections for data security.

An example is given of each of these measures. Internal user processes may involve an authorization process for access to the data. Within business applications, a four-eyes principle (i.e., two observers) can be realized and encryption can be introduced. In the IT infrastructure, security can be arranged by the application of stringent configuration of security parameters. Finally, security can be guaranteed via IT management processes by installing preventative processes for patching and access control, for example, as well as processes for detection and response should the access regulations be breached.

Demonstrability of data security

It is precisely in cases of transparent information security that it is advisable to look under the hood periodically in order to control whether or not confidence in data security is justified.

In this process, the 3-lines-of-defense model stimulates efficiency. Self-control also helps the timely detection of security risks.

Especially when it is steered through feeling, an organization should investigate whether or not adequate security measures have been installed, but this should be done in moderation.

The demonstration of adequate security on the basis of the 3-lines-of-defense model guarantees that the co-coordinators themselves assume their responsibility, and subsequently efficiently and effectively demonstrate status to the management of an organization, so that the management can assume its own responsibility for the data it administers, its own and those of his customers. The efficient and effective input of departments such as IT, risk management, security, and internal audit are thus supported.

Prior to the demonstration of data security it is advisable to determine its scope: which data and IT services should be shown to be adequately protected, and for which data and IT services is this not necessary? Do all sensitive data within the organization light up on the radar? By periodically identifying dataflows across the width of the organization, sensitive data remains on the radar. In this context, one can think of project data on file servers, for example, or customer data on an old server where the corresponding application is still active without anyone knowing about it, even if there are no longer any users. And there may be data on old media or in the cloud.

With scoping, it is important to focus on the value of the data to the organization itself, to other stakeholders, and to hackers for example. Consider also the possible effects of WikiLeaks or the publicizing of data after a burglary.

Development of threats in the chain, and demands imposed

Organizations need not always be involved in the development of threats. These threats may also lie beyond the organization. For instance, various organizations in sectors such as security and transport have to admit that if GSM networks fail, their own services to customers will also fail.

Accordingly, it is advisable to examine the chains periodically, and to show that adequate responsibility has been taken within this domain. In the case of dependence upon GSM networks, the question may be asked concerning whether or not back-up measures should be realized.

Current compliance of measures with previously determined demands

Please ensure that, in the monitoring of compliance, both process-oriented and technology-oriented measures are given sufficient attention (see also Figure 3). In the recent past, considerations of efficiency and perhaps even of knowledge have ensured that attention has been increasingly paid to the monitoring of processes. However, this is no guarantee that the correct technology is being maintained. Technology monitoring requires explicit attention!

Risk assessment of the current demands and non-compliances

Monitoring can show whether or not non-compliances are present. A non-compliance can be accepted or mitigated.

There is an increasing need for a dashboard of non-compliances and potential risks, enabling the management to make satisfactory choices with regard to the non-compliances that are to be accepted or mitigated, as well as the speed with which the mitigation of non-compliances should take place. In this risk evaluation, be careful to only take costs into account, and balance the costs of security against the values to be protected.

In conclusion

More ‘steering through feeling’ will be an important managerial feature in the future, because it turns out to become too complex and expensive to document all data security measures in requirements and to have users and managers remember them all. For measures that are genuinely essential – in other words, those covering the sensitive data and systems – it is important to ensure such measures firmly, and to organize the demonstrability of these measures and report on their outcomes.

Accordingly, the following priorities apply to the management of organizations:

Security awareness
- Remember that the landscape is changing, threats are real and here, security measures cannot provide a hundred per cent security; that has always been the case.
- Security awareness should be constantly stimulated, by periodic campaigns for example.
Data classification and labeling
- Configure data security specifically for your own organization, on the basis of the acknowledged value of data and systems, and the role of the organization in related business chains.
- Restrict formal classification and labeling to the essence.
Security measures
- Lead by example, and be cautious with regard to innovations such as smartphones and tablets. Prevent the management of the organization making unsafe use of these resources and insist, in good time, that only secure use is possible.
- Do not be penny wise and pound foolish, but invest consciously; do not economize on the avoidance of major risks. Consider monitoring, for example. This makes it possible to control whether or not essential security measures are being adequately applied.
Demonstrability
- Apply the 3-lines-of-defense model to security. With a higher degree of maturity in control (evident via demonstrability), protection will become more efficient and also a structured and continuous process.

Access to the cloud

Cloud computing is maturing past the ‘hype’ stage and is considered by many organizations to be the successor to much of the traditional on-premise IT infrastructure. However, recent research among numerous organizations indicates that the security of cloud computing and the lack of trust therein, are the biggest obstacles to adoption. Managing access rights to applications and data is increasingly important, especially as the number and complexity of laws and regulations grow. Control of access rights plays a unique role in cloud computing, because the data is no longer stored on devices managed by the organizations owning the data. This article investigates and outlines the challenges and opportunities arising from Identity and Access Management (IAM) in a cloud computing environment.

Introduction

In recent years, cloud computing has evolved from relatively simple web applications, like Hotmail and Gmail, into commercial propositions such as SalesForce.com and Microsoft Office 365. Research shows that most organizations currently see cloud computing as the IT model of the future. The security of cloud computing and the lack of trust in existing cloud security levels, appear to be the greatest obstacles to adoption ([Chun10]). The growing amount of data, users and roles within modern organizations, and the stricter rules and legislation in recent years concerning data storage for organizations, have made the management of access rights to applications and data increasingly important and difficult. The control of access rights plays a unique role in cloud computing, because data stored in the cloud demands new, often different security measures from the organizations owning the data. Organizations must change how identities and access rights are managed with cloud computing. For example, many organizations have limited experience with the management and storage of identity data outside the organization. Robust Identity & Access Management (IAM) is required to minimize the security risks of cloud computing ([Gopa09]). This article describes the challenges and opportunities arising from Identity & Access Management in cloud computing environments.

What is cloud computing?

Although much has been published on the topic of cloud computing, it remains difficult to form a precise definition for this term.

One of the commonly used definitions is the following ([NIST11]): “Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

KPMG has taken this definition as a starting point and has narrowed it somewhat to the perspective of a recipient of cloud services ([Herm10]):

“Cloud computing, from the perspective of the user, is the usage of centralized computing resources on the Internet. Cloud computing differs from traditional IT via the following characteristics:

Multi-tenancy. Unlike traditional IT, the IT resources in the cloud are shared across multiple users.
Paid services. The user only pays for the use of cloud services and does not invest in additional hardware and software.
Elasticity. The capacity can either increase or decrease at all times.
Internet dependent. The primary network for cloud services is the Internet.
On-demand services. Unlike the greater part of traditional IT, cloud services can be utilized practically immediately.”

Different types of cloud services are available. First and foremost is Software-as-a-Service (SaaS) where software is provided as a cloud service. There is also Platform-as-a-Service (PaaS) where a platform (operating system, application framework, etc.) is offered as a cloud service. Finally, there is Infrastructure-as-a-Service (IaaS) where an IT infrastructure or part thereof (storage, memory, processing power, network capacity, etc.) is offered as a cloud service.

C-2012-0-Sturrus-01

Figure 1. Forms of cloud computing.

What is Identity & Access Management?

Broadly speaking, IAM is the consolidated management of users and corresponding authorizations via a centralized identity register. IAM allows an organization to control who gets access to what and by what means. KPMG uses the following definition of IAM ([Herm05]): “The policies, processes and support systems to manage which users have access to information, IT applications and physical resources and what each user is authorized to do with it.”

IAM is categorized as follows ([KPMG09]):

User management: The activities related to managing end-users within the user administration.
Authentication management: The activities related to the management of data and the allocation (and de-allocation) of resources needed to validate the identity of a person.
Authorization management: The activities related to defining and managing the access rights that can be assigned to users.
Access management: The actual identification, authentication and authorization of end users for utilizing the target system.
Provisioning: The propagation of identities and authorization properties to IT systems.
Monitoring and auditing: The activities required to achieve monitoring, auditing and reporting goals.
Federation: The system of protocols, standards and technologies that make it possible for identities to be transferable and interchangeable between different autonomous domains.

Figure 2. IAM reference architecture.[Click for a larger image]

IAM plays a major role in securing IT resources. IAM faces many challenges when cloud computing is used. IAM processes, such as adding a user, are managed by the cloud provider instead of the organization owning the data. It is difficult for the organization using the cloud service to verify whether a modification has been completed successfully within the administration of the cloud provider. Furthermore, it is harder to check whether the data stored by the cloud provider is only accessible to authorized users. The next section elaborates on the various challenges related to the components of the IAM architecture in a cloud computing environment.

IAM challenges in a cloud computing environment

The existing challenges in managing users and access to information are complemented with new challenges brought along with cloud computing. Originally, the organization itself was responsible for all aspects of IAM. This ranged from maintenance of user administration to the propagation of user rights in the target systems and checking usage based on logging and monitoring.

The introduction of cloud computing has made these activities more complex. The boundaries are blurring between what user and IT resources belong to the “customer” and what belongs to the “cloud provider”. Who owns what resource and carries the accountability that goes with it? What is the difference between accountability and liability? This section summarizes some of the challenges of IAM.

User management

User management deals with the policies and activities within the scope of administering the entire lifecycle of users in the appropriate registers (initial registration, modification and deletion). For example, this could be the HR system for the employees of an organization. The HR system records the recruitment, promotions and dismissal of employees. In addition, user management controls the policies and activities related to granting authorizations to the users registered in the HR database.

An organization that utilizes cloud services may be faced with challenges in user management that are new compared to the traditional on-premise situation. Managing the user life cycle in the traditional IT environment is a challenge, it is even more so in a cloud environment. The organization cannot always maintain control over user administration via their own HR system (or other centralized resource). The cloud provider usually also maintains a user administration system. What happens when users update their information via the cloud provider? How are the managers of the cloud services and their attributes kept up to date? Which laws and regulations (possibly outside own jurisdiction) apply to the storing of personal information? All these issues have to be dealt with again in a cloud computing environment. The allocation of authorizations is also a part of user management. The customer and cloud provider must agree on who is responsible for granting and revoking user rights.

Authentication management

Authentication management includes the processes and procedures for administering the authentication of users. If particular data is very sensitive, stringent authentication may be required to access this data (for example, by using a smart card). Defining and recording these requirements within objects in the form of policies and guidelines is part of authentication management. Authentication management also deals with the issuing and revocation of authentication means (for example, username and password and smart cards).

The following challenges in authentication management are new compared to the traditional on-premise situation: the authentication means for different cloud providers may vary. Sometimes, the cloud provider itself may only use mechanisms that do not match the (security) technical requirements of the customer. It can also be complicated to implement the level of authentication in a uniform way. In addition, synchronization of passwords can be a challenge, especially in environments where the user administration changes quickly or where users must change their own passwords. Finally, it requires that a working Single Sign-On (SSO) environment is maintained for technical integration with the cloud provider. SSO is a collection of technologies that allow the user to authenticate for different services once as a particular user, which allows access to the other services.

Authorization management

Authorization management deals with the policies and activities in relation to defining and administering authorizations. This allows authorizations to be grouped into a single role (based on so-called authorization groups). After granting this role to a user, that user can carry out a particular task or sub-task on certain objects. When a manager welcomes a new team member, he has to grant the appropriate role to the new user. Once the association is made, the authorizations that belong to this role are now available to the new user. As previously described, the granting of these predefined roles to users is carried out via user management.

Likewise for authorization management, there are new challenges when the organization utilizes cloud services. The cloud provider and the customer must agree upon where the authorizations and/or roles are managed. The IAM system must be capable of exchanging (automated) messages with the means of authentication that the cloud provider uses. In many cases, the cloud provider and customer use conflicting role models and the maturity of the role models differ. For example, the cloud provider may have switched over to centrally organized Role-Based Access Control (RBAC), while the customer still uses direct end-user authorizations that is administered in a decentralized manner. In accordance with user management principles, it is necessary to maintain a trusted-relationship on authorization management that is supported by contractual agreements.

Access management

Access management deals with the (operational) processes that ensure that access to IT resources is only granted in conformance with the requirements of the information security policies and based on the access rights associated with the users.

The domain of access management has the following new challenges compared to the traditional on-premise situation: access management requires agreements to be made between the cloud provider, third parties and the customer, on how to appropriately organize access to the target systems. For example, the exchange of authorization data (user names, passwords, rights, and roles) must be fast enough to grant or deny access instantly. The customer and the cloud provider can decide to establish a trusted-relationship supported by certificates and/or a Public Key Infrastructure (PKI).

Provisioning

IAM must ensure that after a role is granted to a user, the user is created in the relevant objects, and that this user is then granted the appropriate authorizations for corresponding objects. Within IAM, this process is called provisioning. Provisioning deals with the manual and/or automatic propagation of user and authorization data to objects. In other words, provisioning consists of creating a user and assigning authorizations to the user objects. Manual provisioning means that a system manager creates a user with authorizations on request. Automatic provisioning means that the system automatically processes these requests without any intervention by a system manager. When a role is revoked from a user then deprovisioning has to take place, which means that the authorizations are revoked from the user.

Provisioning in a cloud environment has the following challenges: the propagation of accounts within the organization and also within the cloud provider is challenging, since technologies and standards are often different for each cloud provider. As more cloud providers deliver services to an organization, it becomes exponentially more complex for the customer to implement provisioning. The creation and modification of accounts and rights on target systems is generally driven by business need. However, it is often the case that less attention is given to deletion because it serves limited business need and it is believed that the security risk does not outweigh the additional effort required to follow through this deprovisioning process effectively. With respect to the contract with the cloud provider, customers often forget to give sufficient attention to the ending of the relationship. It is then unclear what happens to the data and user rights when the cloud provider no longer provides paid services to the customer.

Monitoring and auditing

The final piece in the IAM architecture is the monitoring and auditing process. This process focuses on checking compliance with policies utilized within IAM. This consists of continuously monitoring and auditing the systems and processes.

In the area of monitoring and auditing, the following are new issues compared to the traditional situation: it is a challenge for many customers to set up monitoring and auditing compliance with the requirements of the applicable information security policies. One reason for this is that the customer often does not have insight in what resources the cloud provider utilizes to manage and monitor the IT resources. A consequence of this lack of transparency is that it may be difficult for a customer to achieve full compliance. In particular, the use of accounts with high-level privileges is difficult to monitor.

Options for IAM in a cloud environment

Several options are available for managing identity and access to cloud services ([Blak09], [Cser10]). The ownership of the various IAM processes and attendant monitoring is different for each model. This has a significant impact on the relevant risks and challenges. The option preferred thus depends on the requirements of the organization and the level of cloud service adoption in the organization.

Traditional model

If an organization utilizes part of its IT needs as a cloud service, the components of the IAM framework must work together with the cloud provider. This may be achieved by linking the existing IAM with the cloud provider (see Figure 3). In this case, the organization manages identities and access rights locally and then propagates these to the various cloud providers. For each cloud provider, the authorized users must be added to the directory of the cloud provider. There are several packages on the market that automate the processes of creation, modification and deletion by synchronizing the local directory with the cloud. However, the “connector” that enables the synchronization to occur must be separately developed and maintained for each cloud provider. A drawback is the added complexity in management when there are multiple cloud providers.

Figure 3. Connecting with the cloud provider.[Click for a larger image]

Identification and authentication for cloud services occurs with the cloud provider. Handing these processes over to the provider requires strong confidence in the provider. There are tools on the market that make it possible to link with local SSO applications. With this method the user needs fewer identities to access services. Checking identification and authentication for cloud services is performed by the cloud provider. Strong confidence in the cloud providers and their policies is required.

This option is already actively used by a large Dutch retailer that has linked the local IAM infrastructure to their cloud provider of email and calendar services.

Trusted-relationship model

Another option to allow IAM to have the cloud provider support the IAM of the customer (see Figure 4). The customer manages the local identities and access rights. The users are stored locally in a directory and an access request for a cloud service is authenticated locally. The cloud provider checks the authorizations and validates these using the directory of the customer. The cloud provider thus trusts the IAM of the customer and it is on that basis that the users can utilize the services. Thus, in most cases, duplication of accounts is unnecessary (unless for auditing purposes).

Figure 4. Federated cooperation between customer and provider.[Click for a larger image]

If this option is used, the customer may continue to use the existing access methods to manage the user activities. A disadvantage for this option is that, when there are a large numbers of cloud providers, it is necessary to make agreements with each cloud provider about the confidentiality of the customer’s local IAM. In addition, for many cloud providers, it is impossible to maintain trustworthy and appropriate monitoring of the IAM of all customers.

Identity service provider model

A third option for cooperation between the local IAM of the customer and the cloud provider is using an Identity Service Provider (IdSP) (see Figure 5). The IdSP is a provider of identity services. As in previous models, the customer manages the local identities and access rights. The IdSP is responsible for validating the identity of the user. Both the cloud provider and the customer rely on this third party to validate the identity of users. DigiD and Facebook are examples of organizations that may act as an IdSP and be able to verify digital identities in the future. There are tools on the market that use a third party to manage and validate identities.

Figure 5. Utilization of an identity service provider.[Click for a larger image]

All-in-the-cloud model

The last option is to outsource the entire IAM and utilize it as a cloud service (see Figure 6). In this case, the organization delegates all IAM systems and processes to a third party operating in the cloud itself. The link with all cloud providers is managed and controlled by this third party. Access to local IT resources will also be conducted via the IAM Service. Effectively, all management and control of IAM are outsourced to the cloud.

Figure 6. IAM as a cloud service.[Click for a larger image]

High trust in the IAM service is required. It is difficult for the customer to monitor the status of the processes for either local or cloud services. Currently, there are no fully functioning IAM cloud services available, but it is possible that large IAM providers (for example, IBM, Microsoft and Oracle) will enter this market in the coming years.

Conclusion

By using (public) cloud services, the organization will need to revise its control measures to maintain the required level of security. Whilst security risks may well decrease by transferring selected services to the cloud, risks are likely to increase in certain areas such as IAM. To minimize the risk it is necessary to properly set up the IAM framework. The implementation of necessary changes to IAM in a cloud environment is critical in providing an adequate level of confidence and guarantee security.

The fact that some of the IT resources are no longer contained in the organization itself raises several questions in the IAM domain. Even though liability remains with the organization utilizing services, keeping control of the IAM processes is more difficult because these are often part of the cloud provider’s domain. For user management, it is important that organizations verify whether changes to user data are taken over by the cloud provider. Organizations must comply with company, national and international laws and regulations with regard to personal information. When considering authentication, it is important that the authentication methods and requirements used match those of the cloud provider. Furthermore, the authorization models should align, so that the correct rights are granted to the authenticated users. The processing of both authorizations and authentications must be timely and accurate in order for the partnering organizations to have confidence in the actual use of cloud services. Finally, it is essential that the monitoring and auditing processes meet the requirements of the applicable security policies.

Several options are available for managing identity and access to cloud services. Firstly, the IAM framework can be connected with the cloud provider. The customer itself manages and propagates users and the rights to the cloud provider. It may be possible to automate this process. Identification and authentication occur in the cloud provider domain. A second option is to allow the cloud provider to support the customer’s IAM framework. The use of this trusted-relationship makes it unnecessary to propagate user to all cloud providers. In addition, identification and authentication occurs locally. A third option is to use an IdSP. This is a third party which is trusted by both customers and cloud services providers and validates the identity of users. The last option is to outsource the entire IAM stack and consume IAM as a cloud service altogether.

Which option is the most suitable depends on IAM requirements of the organization and on the type and number of cloud services consumed. The IAM framework should be properly established before cloud services are utilized to minimize risk exposure. Furthermore, it is very important to align the IAM framework with the cloud landscape to allow effective cooperation with the cloud provider and adequate security safeguards.

Literatuur

[Blak09] B. Blakley, The Business of Identity Services, Midvale, Burton Group, 2009.

[Chun10] M. Chung and J. Hermans, From Hype to Future: KPMG’s 2010 Cloud Computing Survey, KPMG Advisory, Amstelveen, 2010.

[Cser10] A. Cser, S. Balaouras and N.M. Hayes, Are You Ready For Cloud-Based IAM?, Cambridge, Forrester Research, 2010.

[Gopa09] A. Gopalakrishnan, Cloud Computing Identity Management, SETLabs Briefings 7 (7), p. 45-54, 2009.

[Herm05] J. Hermans and J. ter Hart, Identity & Access Management: operational excellence or ‘in control’?, Compact 2005/3, p. 47-53.

[Herm10] J. Hermans, M. Chung and W. Guensberg, De overheid in de wolken? (The government in the clouds), Compact 2010/4, p. 11-20.

[KPMG09] KPMG, IAM Methodology, KPMG International, 2009.

[NIST11] NIST, The NIST Definition of Cloud Computing, Information Technology Laboratory, Gaithersburg, National Institute of Standards and Technology, 2011.

Social engineering: the art of deception

In a typical penetration test (hacker test) attempts are made to gain unauthorized access to systems or data by exploiting technical vulnerabilities. The “weakest link” in the information security chain is often overlooked in these tests: users. It appears that this “link” has increasingly become the target of attackers. The media have reported a large number of incidents involving this type of attack ([security.nl]). This is reason enough to also put this “link” to the test within the scope of an audit or security test. This act of “hacking people” is called “social engineering”. This article describes how social engineering tests are performed, provides some real-life examples, and discusses what measures can be taken against such attacks.

What is a social engineering test?

KPMG IT Advisory has performed social engineering assignments for a large number of clients. The purpose of such tests is twofold:

identify the risks to the organization being evaluated
make employees aware of these risks (training)

During the tests, attempts are made to manipulate employees so that unauthorized access to confidential information is obtained. These attempts vary from a simple “phone call test” in which employees are tricked into disclosing passwords or a so-called phishing attack (in which the attacker uses forged emails and/or websites), to a physical attack where a client’s premises are entered by a tester undercover using counterfeited access badges (or sometimes disguised like a pizza delivery person or fireman) to gather confidential information from the inside. The findings are usually quite remarkable. To name just a few, unauthorized access has been gained to safes in banks, heavily secured government areas and large data centers. In several of these cases, the assignment also included a penetration test. In these combined tests, also known as red teaming (Figure 1), the team first has to gain unauthorized physical access to the building and then has to hack internal systems and eventually leave with confidential information without being caught.

C-2012-0-Paques-01

Figure 1. Red teaming is a test approach where different attack techniques are combined to simulate an actual attack.

The main difference between a penetration test where you can attempt to access systems multiple times and a social engineering test is that in the latter the tester usually has only one chance of success. There are no “try-outs”, it must be successful the very first time. The tester has to be prepared for unforeseen situations and must have a made-up story (the pretext) ready in case his presence is being questioned. If his story is not credible, there is a risk of being taken away in handcuffs. The employees of the organization for which the test is performed are generally not informed in advance about the test. Often, only a few executives are aware of the test and even they do not know exactly when the test will be carried out. Security staff is not meant to be put on the alert and take extra precautions. This approach makes it possible to obtain a realistic impression of the risks. As a result of this approach security personnel may take drastic measures if the tester is unmasked as an “intruder” (especially when he has a stack of confidential documents in his possession).

The ingredients of a successful attack

There are two decisive factors that determine the success of a social engineering attack: information and timing. Thorough preparation is crucial. In such a test as much information as possible is assembled about the target prior to the actual attack. About 90% of the time is spent to research and make preparations for the actual hit. Information is gathered not only about the organization in scope (e.g., via the corporate homepage, Google Maps, search engines, newsgroups or job vacancy websites,) but also about the organization’s employees, their hobbies, address and contact info (Facebook, Hyves, LinkedIn etc are very useful). After this step the tester usually makes several telephone calls to the company’s general telephone number and the phone numbers of employees found through publicly available sources. Large organizations often use series of telephone numbers. The known numbers in a series allow for other numbers in the series to be determined and called. When an employee answers, they are told that it must be a wrong number as it is Mister X who is needed (Mister X being a name that was found in the earlier research, for example on LinkedIn). The correct number of Mister X and their name, job title, and department are then verified. Information obtained in this manner can then be used to extract further information. All information that is gained is potentially interesting. For a test on a highly secure data center we went there months before the test and photographed the building from all sides with a camera with a 500mm lens to determine the location of all the cameras and entrances, to observe how employees were dressed, what time they went home, etc. Information like this is used for elaborating a detailed attack scenario. We determine who we will impersonate, what time we must arrive (to walk in with the rush of the daily crowd), the best clothing to wear, and what route to take once we are “in” to avoid as many risks as possible (e.g., cameras and security guards).

The timing of an attack is also very important. Often, the help of an employee is required to get past a gate, fence, reception or other secured entrance. The exact moment that a suitable employee is present may be a matter of seconds. With a good story, improvisation skills for unanticipated situations, the ability to make contact easily and sometimes nerves of steel an attacker might even be able to penetrate the most secure environments.

During an attack it is useful to know what people to approach and who to avoid. For example, secretaries often know a lot about what is happening in a company. Their knowledge can be of tremendous value. However, because they know a lot about what is happening in the company, a good story that is well supported is a prerequisite when you approach them. Complete improvisation may be like a game of Russian roulette and result in a premature and undesired end of the test. Case study 1 describes a test case in which the individuals approached were specifically selected to make the chance of success as high as possible.

Case study 1

A colleague and I carried out an advanced phishing attack on one of our clients. My colleague placed himself at the entrance of the client office building and selectively asked employees who entered whether they wanted to take part in a survey about the upcoming Christmas activity. We focused our “selection” of employees on the younger female employees to minimize the risk of accidentally speaking with managers or IT staff. (They would know whether such a survey existed and thus figure out quite quickly that there was an attack underway.) Beforehand, we had examined the LinkedIn and Facebook profiles of key people in the organization so we could recognize and avoid these “risky people”.

Participants would be included in a raffle for an iPod Touch. The employees who wanted to participate were given a sealed envelope containing a letter explaining the activity and a link to our forged web page with the survey that we set up beforehand. After logging in with their credentials, the employees were presented with ten questions about their ideas for the perfect Christmas activity. They could also supplement these with their own suggestions. After submitting their responses, they were thanked for their participation. Of course, we were not at all interested in the employees’ “party ideas”, but just in their login details. I had taken position around the corner to keep an eye through the window to see whether anything suspect happened inside. If it became necessary, I could warn my colleague via our two-way radio transceiver and inform him that it was time to take to his heels. At the same time I watched my smartphone that provided “real-time” updates on the number of users that logged in on the web page. In a matter of minutes several users had entered their passwords on our web page already. After about 35 minutes, we both left the location in different directions. We estimated that this was the minimum amount of time it would take to be detected. In the discussion with the client afterwards we discovered that only a few minutes passed after we left until two alarmed people came outside to demand an explanation.

Employee training

An important aspect of a social engineering test is to make the employees aware of the risks. Nevertheless, the attack scenarios should be selected in such a way that the impact experienced by employees is kept to the absolute minimum required. Therefore, we do not give the client any details (insofar as possible) about which employees played a role in the tests (for example, which employees did provide their password). Details are anonimized as much as possible. The least sensible thing a client can do (and, of course, highly undesirable, but not inconceivable) is taking disciplinary action against these employees. The outcome of such an action is that employees who do become “victims” of a real social engineering attack may not report it in fear of reprisals and the organization does not become aware of the attack until it is too late and it has to deal with the consequences.

A good follow-up to a social engineering test is to present the results back to all employees so that the test can be a learning experience and they are better prepared against a real attack. We experience that in practice, most untrained employees are susceptible to a social engineering attack and employees can be misled at every level in the organization.

Psychological tricks

For each test the attack scenario is completely different because it is tailored to the client’s specific circumstances. Nonetheless, some fundamental psychological principles or “tricks” are regularly used:

Making a personal connection: mentioning a common problem or interest is typical. Social media can be a valuable source of information. Indicating that you have worked for the same company or play the same sport builds trust. You can also say you have a friend or acquaintance in common. After the connection is made, it is harder for the “victim” to refuse a request.
Time pressure: create a situation where the “victim” does not have enough time to make a proper decision because circumstances are described in such a way that a quick decision must be made. The Windows operating system often shows the name of the last user that logged in (but not the password). Sitting at a user’s (locked) PC, you can usually block that user’s account by entering the wrong password five times. After blocking the account, you can call the help desk and say that you must give an important presentation within five minutes and need to get into your blocked account. Due to the time pressure the help desk employee (after checking that the account is actually blocked) may issue a temporary password and give it over the telephone. Now, you have access to the system.
Referring to a senior person in the organization (authority). This trick often works very effectively combined with the “time pressure” element. Indicate that the “victim” is hindering the actions of a high ranking person in the organization and that the victim must immediately assist with the request. A variation of this is using clothing and accessories that “exude” authority (see also Figure 2). Wearing a suit and tie makes it sometimes much easier to get into a building without being questioned than wearing jeans and a T-shirt. I once entered a bank in a soaking construction worker’s jacket announcing that there was a leak on the floor above. I said something like: “I just want to take a quick look to see if any water is coming through the ceiling.” The staff were happy that they had been warned in time and without asking questions allowed me access to the restricted areas in the building that should only be accessible by bank staff.

C-2012-0-Paques-02

Figure 2. Security badge costing a few dollars that a social engineer can use to “exude” authority.

Asking for help: for example, ask someone to print a file from a USB memory stick that is infected with malware that infects the pc of the victim as soon as the file on the stick is accessed, or borrow an access badge because “you left yours on your desk”. A request made by a man (the tester) to a woman (the victim) and vice versa is usually fulfilled easier than when the gender is the same.
Using recognizable items related to the organization that is being evaluated. Employees may believe they are dealing with a co-worker because you have an access badge (possibly forged), similar style of clothing, business cards, jargon, knowledge of work methods or names of information systems or colleagues (name dropping). All are less likely to prompt critical questions. If the name on the (fake) badge also has a LinkedIn or Facebook profile that refers to the company being evaluated, even the most suspicious people may be convinced that they are dealing with a co-worker.
Another method is to request one employee to give information to another employee (for example, communicate with an internal department to have them forward a “wrongly addressed email”). Using these internal reference points increases credibility. Another example is recording the hold music that companies use when callers are put on hold. You can call an employee, then say after a few minutes: “Wait a minute please, I have to get the other line”. You then put the “victim” on hold and play the hold music that you previously recorded making the victim unconsciously think: “Hey, that’s our music, he must work for our company”.
Indicating that all colleagues of the “victim” have acted the same way so that it makes the request seem completely normal. People are inclined to believe something is correct when others have made the same choice. A variation of this is the gradual escalation of requests (for information). If someone has already fulfilled a number of requests (for example, they looked up trivial information) it is then more difficult to refuse a request for confidential information.
Creating the need to return a favor. Giving people something creates an emotional obligation where they feel they owe you something back. This makes it easier than usual to get someone to fulfill a request. When you have done something for someone (even when they did not ask for it), it becomes more difficult for that person to refuse a request.
Creating the impression that the actual request already is a concession. When all that is needed is five minutes inside, it can be useful to request a tour on the premises. If this is refused, insist that it will only take five minutes to have a quick look around.
Offering something that leads to a personal benefit. For example, send a phishing email with a code to receive a personal Christmas packet.
Creating unexpected situations so that employees (especially security guards) are no longer able to follow their usual routine. We once dressed up as “Sinterklaas” (a traditional Winter holiday figure celebrated in the Netherlands) and his helper and have even penetrated a high security data center in this manner (Figure 3). The data center was at a secluded location and surrounded by high fences with barbed wire, dozens of cameras and an earthen wall that hid the building from view. We called security on the phone a week in advance and pretended to be from the HR department. We told them that we were calling about the Sinterklaas activities at the different locations. To get onto the premises, we first had to get through a checkpoint where a security guard behind bullet-proof glass consulted his colleagues inside the building when we showed up. Somewhat to our surprise, we were allowed to enter the premises and the door was locked again behind us. When we arrived in the data center itself, we walked straight up to a glassed-in security area with five security guards. A quick peak in our heavy bag of “pepernoten” (traditional Sinterklaas cookies) would have sufficed to reveal the recording equipment of the spy camera (Figure 4) and unmask us. “Hello! Well, here we are then!!”, we called out, and instead of putting identification into the tray filled it with pepernoten. After bribing one of the guards with a chocolate letter, they allowed us access. We made a tour through the building and we left again with no problems.
Using distraction such as bringing along that attractive female colleague with a short skirt and high heels.

C-2012-0-Paques-03

Figure 3. The “Sinterklaas and helper” who managed to penetrate the data center.

C-2012-0-Paques-04

Figure 4. A button camera that surreptitiously films security sensitive actions such as password keystrokes.

As mentioned before, for each social engineering test specific attack scenarios are elaborated depending on the specific situation of the client. These scenario’s often use one or more of the aforementioned techniques . In Case study 2, a personal connection was made with the victim, recognition was induced by referring to internal departments, a personal benefit was offered (not losing data) and a compromise was agreed upon (last paragraph). That “help” had been previously given also created the obligation for “compensation“.

Case study 2

In a test case where the goal was to gain unauthorized access to a system, I called an employee to report that there was probably a problem with her system as it was causing an enormous amount of traffic on the network. I said that it would eventually crash her system and in the worst case prevent access to existing data. When I asked whether her laptop was very slow lately, I did indeed receive an affirmative answer (of course). After some random tapping on my keyboard, I said that I had found the problem, emphasized how very difficult it was to solve, but that I was working on it. I hung up and called again after half an hour to indicate that the problem was solved. After she had thanked me emphatically, I hung up.

Two days later, I called again and said that, unfortunately, it turned out that the problem was still present and it appeared that changes needed to be made to her laptop. I asked her whether she could bring her laptop along to the local IT department (that I had already called earlier to determine how the process worked and to verify that there actually was a local service point) to give the impression that I actually worked within her company. The employee said she was very busy and it was very bad timing. I said that we could make an exception and that I could try to solve the problem remotely. I said that we, because of security reasons, never asked users for their passwords over the phone, and therefore I asked her to temporarily change her password to “welcome123” so that I could fix the problem remotely. Two minutes later I was able to login to the laptop and I had access to the confidential data that I wanted.

Methods

Some common methods that are used in a social engineering attack are presented below. These methods partly rely on the previously described psychological “tricks”. The combination of methods constitutes the attack scenario.

C-2012-0-Paques-05

Figure 5. The relationship between methods, tricks, and attack scenario.

Phishing: this is an attack method using forged email messages or web pages that appear to be legitimate such as those of the employer, but which in reality are controlled by the attacker. These email messages and pages are often aimed at collecting employee data (for example, passwords).
Dumpster diving: searching for valuable information by looking through garbage bins, bins by copiers, or containers outside an organization’s premises.
Pretexting: obtaining information under false pretenses (the pretext). For example, calling an employee and pretending you are a colleague.
Tailgating: “hitching” along with an employee through a secured entry gate to get physical access to a secured location.
Reverse Social Engineering: a method in which the “victim” is manipulated so that they ask the social engineer for help. The social engineer creates a problem for the “victim” and then makes himself known as an “expert” who can solve the problem. The social engineer then waits for the “victim” to make a request. Trust is more likely because the “victim” takes the initiative.
Shoulder Surfing: watch when someone enters a password or PIN code. You do not actually have to watch. In several tests we used miniature spy cameras such as a button camera (Figure 4) with which you replace one of the buttons on your jacket. After the entry of a password has been recorded, it can be played back later.
Placement of listening devices (bugs), wireless access point or key logger. Once access is gained to a building, it is often easy to place listening devices. Modern listening equipment is available at low cost. For instance, such a device can dial a previously programmed cell phone number when sound is detected so that the attacker can listen along via the phone (Figure 6). Alternatively, a key logger can be installed (Figure 7). This device can be plugged in between the keyboard and the computer in a few seconds and will then record all keystrokes that are typed in. Current versions of key loggers can then automatically send an email with captured keystrokes to the attacker through a wireless network. Hiding an access point inside a building may also be useful (for example, by hiding it behind a radiator). After it is connected to the network, the attacker can then leave the building. On the outside, say in a car, the attacker then connects to the newly installed access point and then accesses the internal network with little chance of being detected and arrested.

C-2012-0-Paques-06

Figure 6. “Audio bug” with which one can listen in via cell phone calls.

C-2012-0-Paques-07

Figure 7. Key logger that collects all keystrokes.

Malware: malicious software that, for example, collects and forwards passwords to the email address of the attacker. Malware can be installed on the systems by, for example, using an infected PDF file ([Paqu01]). The PDF file can be circulated in different ways, for example, by leaving a USB memory stick containing files titled “2011 payroll” or “fraud investigations in 2011” or similar. Ideal places to leave these sticks are in the restrooms or by the coffee machine. When the “victim” opens the PDF the malware is being run in the background automatically.

In Case study 3, some of the above methods are used. This example shows, amongst other things, how information obtained from one attack can be used in another attack to get even more information.

Case study 3

It was just after eight o’clock in the morning when I parked my car a few hundred feet from the building of one of our clients. I had earlier determined that most employees came to work with their car and parked behind the head office in the private parking lot. It seemed best to mimic this habit because walking through the car park would probably draw attention to my presence. In my car mirror, I kept an eye out for employees driving up to the lot. After about ten minutes, a gray car appeared. Once the car passed me, I merged and followed closely behind. Unfortunately, the car drove past the building of today’s target and I was forced to circle back to my starting position. The second time, I had more luck and after the employee used his access badge to open the gate I could follow closely behind to get into the private car park behind the building. I waited until the employee left his car and entered through the staff entrance at the rear of the building. I walked to the smoking area near the entrance. I grabbed a new pack of cigarettes out of my pocket and lit one. Fortunately, there were no cameras on this side of the building, so I could just quietly wait until an unsuspecting employee joined this non-smoker who was flaunting a cigarette for the occasion. A woman wanting a smoke appeared after a little while. We talked a little and walked back together – through the door opened with her employee badge – into the building. I was inside! I immediately decided to follow her up the stairwell because it appeared that this client had placed card readers on the doors of each floor.

I followed her to the fourth floor and entered the office, once again she politely opened the door for both of us. Luckily, there was a coffee machine so I could stay there for a while and observe the floor without walking myself into a dead-end part of the building. A little further away, I could see some rooms set up for meetings. I took my coffee with me to a meeting room, removed the cable from the VoIP phone and inserted it into my laptop. While my laptop booted up, I cast a glance at the stack of paper that I had grabbed from the bin near the printer while walking by. It included emails with a lot of addresses of employees in the “To” and “CC” fields. Perfect! These would be the “victims” in my next attack.

After my laptop booted, I performed a port scan on port 80 on nearby IP addresses to look for internal web pages. I also used my web browser to try open a few obvious URL’s like “intranet.clientname.com”, “intraweb.clientname.com”, “search.clientname.com”, “directory.clientname.com”, and so on. It did not take me long to find an internal web page. I copied the page and adjusted some text and after fifteen minutes I had put together an “employee of the month” voting page that looked exactly like the company web pages including logos and colors. Then, I started a web server on my laptop so that the newly created page could be accessed via the internal network.

A second limited port scan allowed me to identify an internal mail server that had mail relaying enabled (allowing anonymous email to be sent out). At that moment, I had been in the building for at least twenty minutes and had not been questioned by anyone about what I was doing there. Then, I focused again on the “victims”. First, I sent an email via the mail server identified that contained the content of an email that I had copied from my spam folder, to some of the addresses in the printed emails. I hoped that this email would trigger an out-of-office message from one of the employees. When I then received just such an email, I copied the signature from it and changed the name and function to fictional ones. I now had a web page and an email message that looked exactly like those used in the organization. Then, I created an email with a reminder for the invitation to vote for the “employee of the month”. The message indicated that a random selection of employees could nominate their colleagues for this award. This could be done via an internal web page included in the link at the bottom of the email. Naturally, logging in was required to prevent people from making duplicate votes. The reminder indicated that those who missed the first mail still had the chance to enter their vote up until 12:00 o’clock the same day. I switched to a second window and calmly waited until the password of the first enthusiastic employees appeared in the second window. This took exactly two minutes after sending out the reminder email.

By logging in at the site, the employees, in addition to their password and username, also automatically left behind their IP address. This was all the information that I needed. I started Metasploit (a hacker toolkit) that allowed me to remotely login to the PC of the first survey participant. Meanwhile, I had also found the user in the internal online telephone directory. Unfortunately, it turned out that the first employee worked in the finance department. At this stage, I was really looking for an IT administrator because they often have privileges to access a large number of systems. I decided to dump the local password hashes on the users system. Using the hash of the local administrator account, I tried to authenticate against the system of an arbitrary user on the network. This “trick” has worked at several client sites and was now also successful. Since all (or at least a lot of) desktops where installed from the very same image, the passwords for the local accounts were also identical. At this point, I had been inside for about three quarters of an hour without anyone noticing and I had already taken full control of two systems. Unfortunately, the password hash did not work on the domain controller, so I decided to keep logging into desktop systems until I found a system with a user (or process) that was running with the highest privileges (for example, the IT administrator). After twenty minutes, I found a system where an IT administrator was logged on. The freeware Metasploit tool has a built-in feature allowing you to take over the identity of a user and with it all his privileges. After I took over the identity of IT administrator, I had domain administrator rights and full access to all Windows systems and the data present on the network, including all servers with financial administration and the mailboxes of the board of directors. I made some screenshots and decided that it was time for a second cup of coffee.

Case study 3 shows that it is not always important how many employees are tricked by social engineers. In this particular situation, it was enough for an outsider to deceive only two employees to compromise the entire IT environment.

Countermeasures

Awareness

The keyword in countering social engineering attacks is awareness. More specifically, it is what the targets know about possible attack techniques and their own weaknesses. In one of my assignments, in addition to the usual paper bins alongside printers, the client also placed large enclosed bins for any paper containing confidential information. Nonetheless, the bin for ordinary waste paper provided a huge stack of confidential documents (reports of security incidents, HR information, passwords, and so on). Why? It was probably too much trouble to push the piles of paper through the small slot in the bin for confidential paper and it was just easier to throw it all away in one go.

When clients hear how a trick works at a presentation or training, people often say things like: “you have to be really naive to fall for that, it would never work on me”. Our test results shows differently. Therefore, it is useful to perform a test and confront employees with the results within their organization to really raise awareness. It usually shows that people are not so ready for such an attack as they think they are. It is this that leads to real awareness. In addition to promoting awareness, a test is also quite useful in identifying risks.

Guidelines

Alongside awareness, it is essential to draw up guidelines and continue to check compliance with these. Consider drawing up “ten rules for information security”. An example is as follows:

Never reveal your passwords to others (including IT employees).
Do not share internal information with outsiders.
Adhere to the clean desk and whiteboard policy.
Lock your computer when you leave your workstation.
Do not leave any information behind at the printer.
Use secure waste bins for confidential information.
Verify the identity of the caller when asked for confidential information. (For example, in case of a telephone request, ask the caller to call back on a specific number.)
Never save confidential information locally or on a private PC or device (drive, USB stick).
Immediately alert the security officer about any suspicious activities.
Keep your access badge visible and request colleagues to wear their badge. Any unknown person without a badge should be escorted out of the building and handed over to the reception and/or security.

To ensure that such rules are followed, it is necessary to monitor that employees are actually complying. The outcome of the monitoring (both positive and negative) should be given as feedback to the relevant employees.

Conclusion

After reading this article, you may doubt that the cases described ever happened and that such incidents can succeed in real-life. Unfortunately, the reality is that these and similar attacks occur every day, despite the various security measures. Security personnel, barbed wire fences, access cards, CCTV, alarm systems, and so on, are not enough. Social engineers know how to penetrate into the heart of an organization. Performing a social engineering test can be a good way to identify risks in an organization and raise employee awareness.

Literatuur

[Hadg01] Christopher Hadgany, Social engineering – the art of human hacking, 2010.

[Mitn01] Kevin D. Mitnick and William L. Simon, The Art of Deception, 2002.

[Paqu01] Matthieu Paques, Hacking with PDF files, https://www.compact.nl/articles/hacken-met-pdf-files/.

[security.nl] : articles concerning social engineering attacks, http://www.security.nl/tag/social%20engineering.

Toegang tot de wolken

Cloud computing is het hypestadium aan het ontgroeien en wordt door veel organisaties als een potentiële opvolger van de traditionele IT gezien. Echter, uit onderzoek onder organisaties blijkt dat de beveiliging van cloud computing en het vertrouwen daarin de grootste obstakels zijn voor adoptie. Voornamelijk door de groeiende hoeveelheid wet- en regelgeving is controle op toegangsrechten tot applicaties en data steeds belangrijker geworden. Deze controle speelt een bijzondere rol bij cloud computing, omdat een groot deel van de IT niet meer in eigen handen is. Dit artikel geeft antwoord op de vraag: Wat zijn de uitdagingen en mogelijkheden van Identity and Access Management (IAM) in een cloudomgeving?

Introductie

De afgelopen jaren is cloud computing uitgegroeid van relatief simpele webapplicaties, zoals Hotmail en Gmail, tot commerciële proposities zoals SalesForce.com en Microsoft BPOS. Uit onderzoek blijkt dat het grootste deel van de organisaties cloud computing als het IT-model van de toekomst ziet. Beveiliging van cloud computing en het vertrouwen daarin blijken de grootste obstakels te zijn voor adoptie ([Chun10]). Door de groeiende hoeveelheid data, gebruikers en rollen binnen moderne organisaties en de strenger wordende regels en wetgeving op het gebied van de opslag van data van organisaties in de afgelopen jaren, is de controle op toegangsrechten tot applicaties en data nog belangrijker geworden. Dit speelt een bijzondere rol bij cloud computing omdat een groot deel van de IT niet meer in eigen handen is. Dit brengt (soms grote) veranderingen met zich mee voor het beheer van identiteiten en toegangsrechten. Bijvoorbeeld het beheer en de opslag van identiteitsgegevens buiten het eigen domein is iets waar veel organisaties beperkte ervaring mee hebben. Robuust Identity & Access Management (IAM) is vereist om de veiligheidsrisico’s van cloud computing te minimaliseren ([Gopa09]). Dit artikel gaat in op de uitdagingen en mogelijkheden van Identity & Access Management voor een cloudomgeving.

Wat is cloud computing?

Hoewel er veel gepubliceerd wordt over het thema cloud computing, blijft het lastig om een eenduidige definitie te vormen voor deze term.

Eén van de veelgebruikte definities is die van het US National Institute of Standards and Technology (NIST, 2011): ‘Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.’

KPMG heeft deze definitie als uitgangspunt genomen, maar iets aangescherpt naar het perspectief van de afnemer van clouddiensten ([Herm10]):

‘Cloud computing staat, vanuit het perspectief van de afnemer, voor het afnemen van gecentraliseerde IT-middelen over het internet. Cloud computing onderscheidt zich van traditionele IT door de volgende karakteristieken:

Multi-tenancy. In tegenstelling tot de traditionele IT worden de IT-middelen bij cloud computing zoveel mogelijk gedeeld over meerdere afnemers.
Huur van diensten. De afnemer betaalt alleen voor het gebruik van de clouddiensten en investeert niet in additionele hard- en software.
Elasticiteit. Met elasticiteit wordt bedoeld dat de capaciteit te allen tijde zowel vergroot als verkleind kan worden.
Afhankelijk van het internet. Het primaire netwerk voor clouddiensten is het internet.
Diensten op aanvraag. In tegenstelling tot het grootste deel van de traditionele IT, kunnen clouddiensten vrijwel direct in gebruik worden genomen.’

Er zijn verschillende vormen van clouddiensten beschikbaar. Allereerst is er de Software-as-a-Service (SaaS)-variant, waarbij software wordt aangeboden als een clouddienst. Daarnaast is er de Platform-as-a-Service (PaaS)-variant, waarbij een platform (operating system, applicatieframework, etc.) als clouddienst wordt aangeboden. Tot slot is er ook de Infrastructure-as-a-Service (IaaS)-variant, waarbij een IT-infrastructuur of onderdeel daarvan (opslag, geheugen, rekenkracht, netwerkcapaciteit, etc.) als clouddienst wordt aangeboden.

C-2011-2-Sturrus-01

Figuur 1. Vormen van cloud computing.

Wat is Identity & Access Management?

Kortweg houdt IAM in dat het beheer van gebruikers en bijbehorende autorisaties in brede zin centraal staat, en daarbij uitgaat van een centraal beschikbare registratie van identiteiten. Met IAM kan een organisatie beheersen wie toegang krijgt tot wat en met welke middelen. KPMG hanteert de volgende definitie van wat IAM is ([Herm05]): ‘Het beleid, de processen en ondersteunende systemen die managen welke gebruikers toegang verkrijgen tot informatie, IT-toepassingen en fysieke resources en wat iedere gebruiker gerechtigd is hiermee te doen.’

IAM is als volgt onder te verdelen ([KPMG09]):

Gebruikersbeheer: de activiteiten gerelateerd aan het beheren van eindgebruikers binnen de gebruikersadministratie.
Authenticatiebeheer: de activiteiten gerelateerd aan het beheer van de gegevens en de uitgifte (en inname) van middelen die nodig zijn voor het valideren van de identiteit van een persoon.
Autorisatiebeheer: de activiteiten gerelateerd aan het definiëren en beheren van de toegangsrechten die aan gebruikers kunnen worden toegewezen.
Toegangsbeheer: het daadwerkelijk identificeren, authenticeren en autoriseren van eindgebruikers tijdens gebruik van het doelsysteem.
Provisioning: het op de IT-doelsystemen configureren (aanmaken, wijzigen, verwijderen) van gebruikers- en autorisatiegegevens zodat gebruikers het systeem kunnen benaderen. Dit wordt in het Nederlands vaak ‘propageren’ genoemd.
Monitoren en auditing: het controleren van naleving van het beleid binnen de hiervoor genoemde IAM-processen. Het beleid kan bestaan uit interne richtlijnen, maar ook uit wet- en regelgeving vanuit externen zoals de overheid of een toezichthoudende instantie.
Federatie: het stelsel van afspraken, standaarden en technologieën die het mogelijk maken om identiteiten overdraagbaar en uitwisselbaar te maken tussen diverse autonome domeinen.

C-2011-2-Sturrus-02

Figuur 2. IAM-referentiearchitectuur.

IAM speelt een grote rol in het beveiligen van IT-middelen. IAM komt in een ander daglicht te staan indien er cloud computing wordt gebruikt. IAM-processen, zoals ‘het toevoegen van een gebruiker’, zijn bij het gebruik van een clouddienst in mindere mate onder eigen controle. Het is voor een afnemer lastig te controleren of het doorvoeren van een wijziging volledig (dus in alle doelobjecten) wordt doorgevoerd bij de cloudaanbieder. Daarnaast is niet in alle gevallen goed te controleren of de opgeslagen data bij de cloudaanbieder enkel toegankelijk zijn voor geautoriseerde gebruikers of dat deze ook toegankelijk zijn voor anderen. In de volgende paragraaf wordt dieper ingegaan op de verschillende uitdagingen voor de onderdelen van de IAM-architectuur in een cloudomgeving.

IAM-uitdagingen in een cloudomgeving

Cloud computing brengt naast bestaande ook nieuwe uitdagingen voor het beheer van gebruikers en de toegang tot informatie. Van oorsprong was de organisatie zelf verantwoordelijk voor alle aspecten van IAM; van het bijhouden van de gebruikersadministratie tot het propageren van gebruikersrechten in de doelsystemen en het controleren van gebruik op basis van logging en monitoring.

Met de komst van cloud computing is dit complexer geworden. De grenzen vervagen tussen welke gebruikers en IT-middelen ‘van de afnemer’ zijn en welke ‘van de cloudaanbieder’. Waar ligt eigenaarschap en daarmee verantwoordelijkheid? Wat is het verschil tussen verantwoordelijkheid en aansprakelijkheid? Deze paragraaf geeft een opsomming van enkele uitdagingen op het gebied van IAM.

Gebruikersbeheer

Gebruikersbeheer richt zich op het beleid en de activiteiten in het kader van het beheren van de gehele levenscyclus van gebruikers in de daarvoor bestemde registraties (initiële vastlegging, wijziging en verwijdering). Voor de medewerkers van een organisatie kan dit bijvoorbeeld een HR-systeem zijn. In het HR-systeem wordt de in-, door- en uitstroom van medewerkers onderhouden. Daarnaast beheerst het gebruikersbeheer het beleid en de activiteiten gericht op het toekennen van autorisaties aan deze in de registraties vastgelegde gebruikers.

Een organisatie die clouddiensten afneemt kan te maken krijgen met uitdagingen op het gebied van gebruikersbeheer die nieuw zijn ten opzichte van de traditionele, on-premise, situatie. Het beheren van de levenscyclus van gebruikers is in de traditionele IT vaak al een uitdaging. Dit geldt in het bijzonder voor een cloudomgeving, waar de organisatie niet altijd via het eigen HR-systeem (of een andere centrale bron) de controle kan houden over de gebruikersadministratie. Vaak zal de cloudaanbieder ook een administratie bijhouden van gebruikers. Wat gebeurt er als eindgebruikers hun gegevens actualiseren via de cloudaanbieder? Hoe worden de beheerders van de clouddiensten en hun attributen (de gegevens die bekend zijn over een account, zoals bijbehorende eindgebruiker of verloopdatum) bijgehouden? Welke wet- en regelgeving is van toepassing bij het (buiten het eigen rechtsgebied) opslaan van persoonsgegevens? Dit zijn allemaal vragen die met cloud computing (op)nieuw aan de orde komen. Ook het toewijzen van autorisaties (gebruikersrechten) is onderdeel van gebruikersbeheer. De afnemer en de cloudaanbieder moeten afspreken wie verantwoordelijk is voor het toewijzen en ontnemen van rechten aan gebruikers.

Authenticatiebeheer

Authenticatiebeheer omvat de processen en procedures voor het beheren van de authenticatie van gebruikers. Wanneer bepaalde gegevens zeer gevoelig zijn, kan het zo zijn dat voor toegang tot deze gegevens een sterke authenticatie vereist wordt (bijvoorbeeld op basis van een smartcard). Het bepalen en vastleggen van deze eisen in objecten, in de vorm van beleid en richtlijnen, vindt plaats binnen het authenticatiebeheer. Daarnaast richt het authenticatiebeheer zich op het beheren (uitgeven en intrekken) van de authenticatiemiddelen (bijvoorbeeld gebruikersnaam/wachtwoord en smartcards) zelf.

Enkele volgende uitdagingen op het gebied van authenticatiebeheer zijn nieuw ten opzichte van de traditionele, on-premise, situatie. De authenticatiemiddelen voor de verschillende cloudaanbieders kunnen per afnemer verschillen. Soms zelfs kan de cloudaanbieder alleen gebruikmaken van mechanismen die niet overeenkomen met de (beveiligings)technische vereisten van de afnemer. Het kan ook ingewikkeld zijn om het authenticatieniveau op uniforme wijze te implementeren. Daarnaast kan synchronisatie van wachtwoorden een uitdaging zijn, in het bijzonder in omgevingen waar de gebruikersadministratie snel wisselt of waar de gebruikers het wachtwoord zelf moeten aanpassen. Tot slot vraagt het werkend houden van een Single Sign-On (SSO) omgeving om technische integratie met de cloudaanbieder. SSO is een verzameling technologieën die het mogelijk maken de gebruiker eenmalig te authenticeren voor verschillende diensten: door eenmalig in te loggen kan een gebruiker dan overal bij.

Autorisatiebeheer

Autorisatiebeheer richt zich op het beleid en de activiteiten ten aanzien van het definiëren en beheren van autorisaties. Zo worden autorisaties gegroepeerd in een rol (op basis van zogenoemde autorisatiegroepen). Na toekenning van deze rol aan een gebruiker kan deze gebruiker een bepaalde (deel)taak in objecten uitvoeren. Als een manager een nieuw teamlid verwelkomt, geeft hij of zij idealiter aan welke rol bij deze gebruiker hoort. Als deze koppeling gemaakt is, krijgt de nieuwe eindgebruiker de beschikking over de autorisaties die bij deze rol horen. Zoals eerder beschreven, geschiedt het toekennen van deze voorgedefinieerde rollen aan gebruikers door middel van het gebruikersbeheer.

Voor autorisatiebeheer geldt ook dat er nieuwe uitdagingen zijn als de organisatie clouddiensten gaat afnemen. De cloudaanbieder en de afnemer zullen overeen moeten komen waar de autorisaties en/of rollen worden beheerd. Het IAM-systeem moet in staat zijn (geautomatiseerde) berichten uit te wisselen met de authenticatiemiddelen die de cloudaanbieder gebruikt. In veel gevallen hanteren de cloudaanbieder en afnemer verschillende rolmodellen en verschilt de volwassenheid van het rolmodel. De cloudaanbieder kan bijvoorbeeld geheel overgestapt zijn op centraal georganiseerde Role-Based Access Control (RBAC), terwijl de afnemer nog gebruikmaakt van directe autorisaties voor eindgebruikers, welke decentraal beheerd worden. In overeenstemming met gebruikersbeheer is het noodzakelijk voor autorisatiebeheer een vertrouwensrelatie te onderhouden, die door contractuele afspraken wordt ondersteund.

Toegangsbeheer

Toegangsbeheer richt zich op de (operationele) processen die ervoor zorgen dat toegang tot IT-middelen alleen verleend wordt conform de vereisten van het informatiebeveiligingsbeleid en op basis van de toegangsrechten die aan gebruikers zijn gekoppeld.

Op het gebied van toegangsbeheer zijn de volgende uitdagingen nieuw ten opzichte van de traditionele, on-premise, situatie. Voor toegangsbeheer dienen afspraken te worden gemaakt tussen de cloudaanbieder, eventuele derde partijen en de afnemer om toegang tot de doelsystemen adequaat te organiseren. De uitwisseling van autorisatiegegevens bijvoorbeeld (gebruikersnamen, wachtwoorden, rechten, rollen) dient snel genoeg te zijn om vrijwel direct toegang te verlenen of te weigeren. De afnemer en de cloudaanbieder kunnen beslissen hiervoor gebruik te maken van een vertrouwensrelatie die ondersteund wordt door certificaten en/of een Public Key Infrastructure (PKI).

Provisioning

IAM dient ervoor te zorgen dat na toekenning van een rol aan een gebruiker, de gebruiker in de betreffende objecten wordt aangemaakt en deze gebruiker de benodigde autorisaties in het betreffende object krijgt toegewezen. Dit proces wordt binnen IAM provisioning genoemd. Provisioning richt zich op het handmatig en/of geautomatiseerd propageren van gebruikers- en autorisatiegegevens naar objecten. Met andere woorden: provisioning betreft het aanmaken van een gebruiker en toekennen van autorisaties aan deze gebruiker in objecten. Handmatige provisioning betekent dat een systeembeheerder op basis van een verzoek autorisaties in een object implementeert. Automatisch betekent dat een centraal systeem de autorisaties geautomatiseerd, zonder tussenkomst van een systeembeheer, in objecten verwerkt. Wanneer een rol aan een gebruiker wordt ontnomen start deprovisioning, wat inhoudt dat de autorisaties in de objecten aan de gebruiker worden ontnomen.

Provisioning in een cloudomgeving brengt vaak de volgende uitdagingen met zich mee. Het propageren van accounts binnen de afnemende organisatie en binnen de organisatie van de cloudaanbieder kan nieuwe uitdagingen opleveren omdat de technologieën vaak verschillend zijn per cloudaanbieder. Naarmate meer aanbieders clouddiensten aan de organisatie leveren, wordt het voor de afnemer exponentieel complexer om provisioning in te richten. Het aanmaken en wijzigen van accounts en rechten op doelsystemen wordt over het algemeen gedreven door een ‘business-need’. Echter, er is voor het verwijderen vaak minder aandacht, omdat het beveiligingsrisico niet geacht wordt op te wegen tegen de additionele inspanning die nodig is om de deprovisioning uit te voeren. In cloudovereenkomsten wordt vaak door de afnemer vergeten aandacht te besteden aan het opheffen van de relatie. Het kan dan onduidelijk zijn wat er met de gebruikersgegevens en rechten gebeurt als de cloudaanbieder niet langer door de afnemer wordt ingehuurd.

Monitoring en audit

Als laatste kent de IAM-architectuur het proces monitoring & audit. Dit proces richt zich op het controleren van de naleving van het beleid dat van toepassing is binnen IAM. Dit bestaat uit constante monitoring en auditing op basis van rapportages.

Op het gebied van monitoring en audit zijn de volgende zaken nieuw ten opzichte van de traditionele situatie. Het is voor veel afnemers een uitdaging monitoring en audit in te richten conform de vereisten van het geldende informatiebeveiligingsbeleid. Een van de redenen hiervoor is dat het voor de afnemer vaak onduidelijk is welke middelen de cloudaanbieder inzet om het gebruik van IT-middelen te monitoren. Als gevolg van dit gebrek aan transparantie kan het lastig of zelfs onmogelijk zijn voor een afnemer om compliancerapportage af te dwingen op basis van vooraf afgesproken criteria. In het bijzonder het gebruik van accounts met hoge rechten is een uitdaging voor veel organisaties. Dit is vooral van toepassing bij het inrichten of gebruiken van de IT-middelen van de cloudaanbieder zelf.

Opties voor IAM in een cloudomgeving

Om identiteiten en de toegang tot clouddiensten te kunnen beheren, zijn verscheidene opties mogelijk ([Blak09], [Cser10]). Het eigendom van de verschillende IAM-processen en de controle erop is bij ieder model anders, dit heeft een aanzienlijk effect op de risico’s en uitdagingen die van toepassing zijn. Het is daarom afhankelijk van de eisen van de organisatie en de hoeveelheid clouddiensten die worden afgenomen welke optie de voorkeur heeft.

Traditionele koppeling

Indien een organisatie een deel van de IT-middelen als clouddienst gaat afnemen, zullen de onderdelen uit het IAM-raamwerk moeten samenwerken met de cloudaanbieder. Dit kan door de bestaande IAM te koppelen met die van de cloudaanbieder (zie figuur 3). In dit geval beheert de organisatie lokaal de identiteiten en toegangsrechten, en propageert deze naar de verschillende cloudaanbieders. Voor iedere cloudaanbieder zullen de geautoriseerde gebruikers moeten worden toegevoegd aan de directory van de cloudaanbieder. Er zijn verschillende pakketten op de markt die de processen van het aanmaken, wijzigen en verwijderen automatiseren door de lokale directory te synchroniseren met de cloud. Echter, de zogenaamde ‘connector’ die het mogelijk maakt om deze synchronisatie tot stand te brengen, moet voor iedere cloudaanbieder apart worden ontwikkeld en onderhouden. Een nadeel hiervan is dat bij meerdere cloudaanbieders het overzicht en beheer complexer wordt.

C-2011-2-Sturrus-03

Figuur 3. Koppeling met de cloudaanbieder.

Identificatie en authenticatie voor clouddiensten vindt plaats bij de cloudaanbieder. Het uit handen geven van deze processen maakt een sterk vertrouwen in de aanbieder noodzakelijk. Er zijn pakketten op de markt die dit kunnen koppelen met lokale SSO-toepassingen. Op deze manier heeft de gebruiker minder identiteiten nodig om toegang te krijgen tot de diensten. De controle op de identificatie en authenticatie voor clouddiensten is in handen van de cloudaanbieder. Dit maakt het noodzakelijk om sterk vertrouwen te hebben in de cloudaanbieders en het door hen gevoerde beleid.

Deze optie wordt bijvoorbeeld al actief toegepast bij een grote Nederlandse retailer die de lokale IAM-infrastructuur gekoppeld heeft aan de aanbieder van e-mail en kalenderdiensten via de cloud.

Federatieve samenwerking

Een andere mogelijkheid om IAM te laten samenwerken met clouddiensten is om de cloudaanbieder te laten steunen op het IAM van de afnemer (zie figuur 4). De afnemer beheert lokaal de identiteiten en toegangsrechten. De gebruikers staan lokaal opgeslagen in een directory en bij het toegang vragen tot een clouddienst wordt lokaal geauthenticeerd. De cloudaanbieder controleert de autorisaties en valideert met behulp van de directory van de afnemer. De cloudaanbieder vertrouwt daarmee op de IAM van de afnemer en staat op grond daarvan de gebruikers toe gebruik te maken van de afgenomen diensten. Het dupliceren van accounts is zodoende in de meeste gevallen niet noodzakelijk (tenzij bijvoorbeeld voor auditdoelstellingen).

C-2011-2-Sturrus-04

Figuur 4. Federatieve samenwerking tussen afnemer en aanbieder.

Indien deze optie wordt benut, kan de afnemer gebruik blijven maken van de bestaande methoden om toegangscontrole uit te oefenen over de gebruikersactiviteiten. Een nadeel van deze optie is dat het bij grote aantallen cloudaanbieders noodzakelijk is met iedere cloudaanbieder afspraken te maken over het vertrouwen in het lokale IAM van de afnemer. Daarnaast is het voor veel cloudaanbieders onmogelijk om voor alle afnemers vertrouwen en voldoende controle te kunnen houden in het IAM van de afnemer.

Identity-serviceprovider

Een derde mogelijkheid om de samenwerking tussen het lokale IAM van de afnemer en de cloudaanbieder mogelijk te maken is door een Identity Service Provider (IdSP) in te schakelen (zie figuur 5). Een IdSP is een aanbieder van identiteitsdiensten. Net als in de voorgaande modellen beheert de afnemer lokaal de identiteiten en toegangsrechten. De IdSP heeft de taak om de identiteit van de gebruikers te valideren. Zowel de cloudaanbieder als de afnemer vertrouwt op deze derde partij voor de validatie van de identiteit van de gebruikers. DigiD en Facebook zijn voorbeelden van organisaties die in de toekomst mogelijk als IdSP zullen fungeren en digitaal identiteiten kunnen verifiëren. Er zijn pakketten op de markt die gebruikmaken van een derde partij voor het beheer en de validatie van identiteiten.

C-2011-2-Sturrus-05

Figuur 5. Inschakeling van een identity-serviceprovider.

IAM als clouddienst

De laatste optie is om de gehele IAM uit te besteden en af te nemen als een clouddienst (zie figuur 6). In dit geval delegeert de organisatie alle IAM-systemen en -processen volledig aan een derde partij. De koppeling met alle cloudaanbieders wordt door deze derde partij beheerd en gecontroleerd. Toegang tot lokale IT-middelen zal ook via de IAM-dienst verlopen. Effectief wordt het gehele beheer van en de controle op IAM uit handen gegeven.

C-2011-2-Sturrus-06

Figuur 6. IAM als clouddienst.

Het vertrouwen in deze IAM-aanbieder is essentieel, het is voor de afnemer lastig te controleren hoe de processen zowel naar lokale als clouddiensten verlopen. Op dit moment zijn er nog geen volledig functionerende IAM-clouddiensten beschikbaar, maar het is mogelijk dat de grotere IAM-aanbieders (bijvoorbeeld IBM, Microsoft en Oracle) deze markt gaan betreden in de komende jaren.

Conclusie

Indien de publieke vorm van cloud computing wordt gebruikt binnen de organisatie, is een deel van de IT-middelen niet meer in eigen handen. Om de risico’s hiervan te minimaliseren is een goede inrichting van IAM noodzakelijk. Het doorvoeren van de juiste aanpassingen aan IAM in een cloudomgeving is van groot belang om vertrouwen en een adequaat niveau van beveiliging te kunnen garanderen.

Het gegeven dat bij cloud computing niet alle IT-middelen eigendom zijn van de organisatie die de clouddiensten afneemt, levert veel vragen op het gebied van IAM op. Terwijl de aansprakelijkheid bij de afnemende organisatie blijft liggen, is het houden van controle op de IAM-processen een stuk lastiger, doordat deze vaak deels bij de cloudaanbieder liggen. Voor het gebruikersbeheer is het belangrijk dat organisaties nagaan of wijzigingen in de gebruikersgegevens volledig worden doorgevoerd bij de cloudaanbieder. Daarnaast is het belangrijk om kennis te nemen van de wet- en regelgeving die van toepassing is op persoonsgegevens. Als men kijkt naar authenticatie, is het belangrijk dat de gebruikte authenticatiemiddelen en de vereisten daarvan overeenkomen met deze van de cloudaanbieder. Daarnaast is overeenstemming van de autorisatiemodellen belangrijk, om de juiste rechten aan de geauthenticeerde gebruikers te kunnen toekennen. De verwerking van zowel autorisaties als authenticaties moet snel en accuraat genoeg zijn, om vertrouwen te hebben in het toegangsbeheer tot clouddiensten. Verder is afstemming over het propageren van gebruikers en rechten belangrijk om zekerheid te hebben over wat er met deze gegevens gebeurt als een clouddienst niet langer wordt afgenomen. Tot slot is het essentieel dat de monitoring- en auditprocessen worden ingericht naar de vereisten van het geldende veiligheidsbeleid. Veelal moeten er harde afspraken over compliancerapportages worden gemaakt om aan het geldende veiligheidsbeleid te kunnen voldoen.

Om identiteiten en de toegang tot clouddiensten te beheren, is een aantal opties mogelijk. Allereerst kan een koppeling van het IAM worden gemaakt met de cloudaanbieder. De afnemer beheert en propageert zelf de gebruikers en rechten naar de cloudaanbieder. Eventueel kan dit proces worden geautomatiseerd. De identificatie en authenticatie vinden plaats bij de cloudaanbieder. Een tweede optie is om de cloudaanbieder te laten steunen op het IAM van de afnemer. Met behulp van deze vertrouwensrelatie is het niet langer noodzakelijk de gebruikers naar alle cloudaanbieders te propageren. Daarnaast kan identificatie en authenticatie lokaal plaatsvinden. Als derde optie kan er gebruik worden gemaakt van een IdSP. Deze derde partij heeft het vertrouwen van zowel de afnemer als aanbieder van clouddiensten en valideert de identiteit van de gebruikers. Tot slot kan de gehele IAM als clouddienst worden afgenomen, waarbij het grootste deel van de IAM-processen niet meer in eigen handen is.

Het is afhankelijk van de organisatie, het type en de hoeveelheid clouddiensten welke opties het meest geschikt zijn. Het is belangrijk dat het IAM op orde is voordat er clouddiensten worden afgenomen, om zo de risico’s van het gebruik van cloud computing te kunnen minimaliseren. Daarnaast is een goede inrichting van IAM erg belangrijk om een effectieve samenwerking met de cloudaanbieder en voldoende veiligheid te kunnen garanderen.

Literatuur

[Blak09] B. Blakley, The Business of Identity Services, Midvale, Burton Group, 2009.

[Chun10] M. Chung en J. Hermans, From Hype to Future: KPMG’s 2010 Cloud Computing Survey, KPMG Advisory, Amstelveen, 2010.

[Cser10] A. Cser, S. Balaouras en N.M. Hayes, Are You Ready For Cloud-Based IAM?, Cambridge, Forrester Research, 2010.

[Gopa09] A. Gopalakrishnan, Cloud Computing Identity Management, SETLabs Briefings 7 (7), p. 45-54, 2009.

[Herm05] J. Hermans en J. ter Hart, Identity & Access Management: operational excellence of ‘in control’?, Compact 2005/3, p. 47-53.

[Herm10] J. Hermans, M. Chung en W. Guensberg, De overheid in de wolken?, Compact 2010/4, p. 11-20.

[KPMG09] KPMG, IAM Methodology, KPMG International, 2009.

[NIST11] NIST, The NIST Definition of Cloud Computing, Information Technology Laboratory, Gaithersburg, National Institute of Standards and Technology, 2011.

Iedereen een supercomputer

Computers worden ieder jaar krachtiger en krachtiger, zo ook pc’s om spelletjes mee te spelen. Recente ontwikkelingen op het gebied van de grafische kracht van de hedendaagse computers zorgen niet alleen voor oogverblindend mooie spelletjes, maar hebben ook nog een effect waar wellicht niet iedereen aan denkt: de grafische kaart in onze moderne pc blijkt uitermate geschikt om wachtwoorden te achterhalen. En de grafische kaart beschikt hiervoor ook nog eens over een flinke dosis meer kracht dan de reguliere processor in onze pc’s. Hierdoor is het mogelijk dat wachtwoorden die we voorheen sterk genoeg achtten nu opeens makkelijk te achterhalen zijn door hackers. Maar ook door uw buurjongen met zijn spelcomputer.

Inleiding

Wachtwoorden worden versleuteld opgeslagen op computersystemen. Deze versleuteling wordt toegepast zodat het voor een inbreker niet al te gemakkelijk is om de oorspronkelijke wachtwoorden te achterhalen. Nadat een hacker heeft ingebroken op een computersysteem kan hij op zoek gaan naar toegang tot applicaties en andere systemen. Een befaamd middel voor het verkrijgen van meer toegang is het ‘kraken’ van versleutelde wachtwoorden die op het systeem aanwezig zijn. Het kraken van deze wachtwoorden kan met diverse technieken, die we later zullen bespreken, maar de gemene deler bij deze technieken is dat het achterhalen van wachtwoorden computerkracht kost. Zelfs zoveel computerkracht dat als het wachtwoord maar enigszins moeilijk is, we het als ‘onkraakbaar binnen afzienbare tijd’ kunnen beschouwen.

Echter, de ontwikkelingen op het gebied van computerspelletjes hebben ervoor gezorgd dat iedere moderne pc uitgerust is met een aparte insteekkaart dat de zware grafische taken van deze spelletjes op zich neemt. Deze grafische kaart wordt ook wel GPU (Graphics Processing Unit) genoemd. De kracht van deze GPU’s is onlangs sterk toegenomen. Deze ontwikkeling maakt nog mooiere en realistischere spelletjes mogelijk maar heeft ook nadelige gevolgen voor de effectiviteit van uw wachtwoordbeleid. De kracht van de GPU’s kan namelijk beter gebruikt worden voor het achterhalen van wachtwoorden dan traditionele processors.

In dit artikel bespreken wij de wachtwoordschema’s die uw computerprogramma’s gebruiken voor het opslaan van wachtwoorden, de aanvalstechnieken die hackers gebruiken om wachtwoorden te achterhalen en waarom grafische kaarten voor deze taak zo geschikt zijn. Vervolgens komt aan de orde wat dit voor invloed heeft op uw wachtwoordbeleid en hoe u uw wachtwoordbeleid sterker en uw wachtwoorden veiliger kunt maken.

Wachtwoordschema’s

Wachtwoorden worden niet zomaar als platte tekst in een database opgeslagen, dan zou het wat al te makkelijk zijn om deze te achterhalen. Wanneer de gebruiker van een bepaalde service voor het eerst zijn of haar wachtwoord kiest, wordt dit door een wachtwoordschema versleuteld opgeslagen. Wachtwoordschema’s zijn gebaseerd op cryptografische hashfuncties. Dit zijn wiskundige functies die een gegeven input (wachtwoord) zo door elkaar husselen dat de uitkomst (wachtwoordhash) niet makkelijk is terug te rekenen naar de invoer (zie figuur 1). Dit maakt het voor een hacker erg moeilijk om met alleen de versleutelde versie van het wachtwoord terug te rekenen naar het oorspronkelijke wachtwoord. Wanneer een aanvaller toch de database in handen krijgt, zijn alle wachtwoorden vooralsnog beschermd. Voorbeelden van veelgebruikte wachtwoordschema’s zijn ‘NTLM’ of ‘Domain Cached Credentials’ voor Windows-omgevingen en ‘MD5-crypt’ of ‘SHA-crypt’ voor Unix-omgevingen.

C-2011-2-Smeets2-01

Figuur 1. Authenticatie via een wachtwoordschema. De gebruiker voert zijn wachtwoord in en het systeem genereert daar een wachtwoordhash van.

Andere eigenschappen van hashfuncties zijn dat dezelfde invoer altijd op dezelfde manier wordt versleuteld en dat de kans erg klein is dat twee verschillende wachtwoorden dezelfde versleuteling hebben. Wanneer de gebruiker zich op een later tijdstip opnieuw wil authenticeren, zal de service zijn of haar wachtwoord opnieuw versleutelen, en dit vergelijken met de al eerder opgeslagen waarde. Wanneer deze waarden hetzelfde zijn, is de authenticatie succesvol. Hoewel het voor een aanvaller moeilijk is om terug te rekenen naar de oorspronkelijke waarden, kan hij wel aan de output zien wanneer twee hashes, en dus twee wachtwoorden, van verschillende gebruikers aan elkaar gelijk zijn. Dit is een zwakheid omdat het aanvallers in staat stelt om eenmalig de versleutelde waarden van alle mogelijke wachtwoorden te berekenen en elke gevonden wachtwoordhash direct te vergelijken met één van deze waarden, wat veel sneller is dan steeds opnieuw alle mogelijkheden doorrekenen. Om deze zwakheid tegen te gaan gebruiken wachtwoordschema’s meestal een salt. Dit is een waarde die uniek is voor elke gebruiker (bijvoorbeeld de gebruikersnaam) en samen met het versleutelde wachtwoord wordt opgeslagen en als tweede invoer wordt meegenomen in de berekening van het wachtwoord. Op deze manier wordt ervoor gezorgd dat twee gebruikers met hetzelfde wachtwoord verschillende versleutelde waarden hebben.

Wachtwoordsterkte wordt altijd bepaald door de hoeveelheid informatie die beschikbaar is. Dus hoe meer informatie beschikbaar is, des te makkelijker het wordt om de ontbrekende informatie (bijvoorbeeld het wachtwoord) te gokken. Een willekeurig gekozen wachtwoord bevat weinig informatie en is dus vrij sterk. Bijvoorbeeld een wachtwoord met kleine letters, hoofdletters, cijfers en speciale tekens (bijvoorbeeld ‘XP68!bK5’) bevat meer te gokken informatie dan het wachtwoord ‘auecdpam’ dat alleen uit kleine letters bestaat. Mensen zijn echter vrij slecht in het bedenken van willekeurige wachtwoorden ([Burr04]) en in combinatie met het feit dat we ook maar een beperkte geheugencapaciteit hebben, wordt het makkelijker om de door mensen bedachte wachtwoorden te gokken. Dit maakt het voor de aanvaller interessant om alle mogelijkheden op te sommen en een voor een te testen. Hoe de aanvaller dit doet zullen we hieronder uitleggen.

Aanvalstechnieken

Een hacker heeft meerdere mogelijkheden om op een systeem in te breken zonder dat de wachtwoorden van gebruikers bekend zijn, bijvoorbeeld kwetsbaarheden in software uitbaten die nog niet zijn voorzien van beveiligingspatches. Toch zal een hacker vaak trachten de wachtwoorden te achterhalen. Dit maakt het namelijk makkelijker om verder door te dringen tot applicaties en overige systemen doordat met kennis van wachtwoorden de reguliere functionaliteit van applicaties kan worden gebruikt.

Afhankelijk van de situatie heeft een aanvaller meerdere mogelijkheden om een wachtwoord te achterhalen. Op hoofdlijnen onderscheiden we twee aanvalscategorieën, waarvan we alleen de tweede categorie verder zullen bespreken in dit artikel:

Online. Deze categorie gaat ervan uit dat een aanvaller alleen via interactie met de server of applicatie een wachtwoord kan raden. Een dergelijke aanval gaat via het netwerk of internet. Computerkracht is in dit scenario irrelevant omdat het netwerkpad tussen aanvaller en doel de vertragende factor is, en niet een gebrek aan computerkracht.

Bescherming tegen deze categorie van aanvallen kan geboden worden door simpele technieken zoals ‘account locking’, waarbij een gebruiker bijvoorbeeld maar drie foutieve pogingen kan doen voordat zijn account wordt geblokkeerd. Ook een tegenmaatregel is ‘delayed response’, wat betekent dat de reactie van de server voor een paar seconden wordt uitgesteld na een foutieve poging. Beide zijn effectieve maatregelen voor online aanvallen.
Offline. Deze categorie gaat ervan uit dat een aanvaller toegang heeft tot de versleutelde wachtwoorden van het systeem. Dit kan bijvoorbeeld door een lek in de database (zie in dit nummer het artikel ‘De meldplicht datalekken’). Wachtwoordschema’s proberen wachtwoorden zo versleuteld op te slaan dat zelfs wanneer een systeem is gecompromitteerd de wachtwoorden niet leesbaar en bruikbaar zijn. Deze versleuteling is te kraken, maar daarvoor is wel computerkracht nodig.

Een aanvalsscenario dat gebruikmaakt van de ‘offline’ categorie is het volgende. In het Windows-domein wordt de wachtwoordhash van de ‘Lokale Administrator’ vaak op de computer van de eindgebruikers opgeslagen (bijvoorbeeld om onderhoud te plegen wanneer er geen verbinding is met het domein). Een kwaadwillende gebruiker kan deze hash van een willekeurige eindgebruikerlocatie afhalen en proberen te achterhalen. Dit achterhalen, ook wel kraken genoemd, gebeurt door wachtwoordhashes te genereren: de aanvaller zal een aantal kandidaat-wachtwoorden kiezen, hier de wachtwoordhash van berekenen door het wachtwoordschema toe te passen en het resultaat van deze berekening vergelijken met de wachtwoordhashes gevonden op het ingebroken systeem. Als het resultaat overeenkomt met de te achterhalen wachtwoordhash, dan weet de aanvaller nu ook het wachtwoord. Hij heeft het immers zelf berekend. Voor dit achterhalen is flink wat rekenkracht nodig. En omdat de aanvaller tracht de versleuteling te kraken, wordt dit proces ook wel het kraken van wachtwoorden genoemd.

Voor dit artikel is alleen de tweede categorie ‘offline’ interessant. Immers, alleen in die categorie wordt gebruikgemaakt van computerkracht. In dit artikel nemen we daarom aan dat een aanvaller de wachtwoordhashes al verkregen heeft en dus in de ‘offline’ aanvalscategorie valt. In deze categorie onderscheiden we de volgende drie aanvalstechnieken die differentiëren hoe de aanvaller de keuze maakt welke potentiële wachtwoorden te kiezen voor het kraken:

Woordenboek. Bij deze techniek kiest de aanvaller ervoor kandidaat-wachtwoorden te gebruiken uit woordenboeken. Een aanvaller zal deze techniek vaak als eerste proberen omdat mensen van nature slecht zijn in het bedenken en onthouden van moeilijke wachtwoorden en daardoor vaak normale woorden als wachtwoord kiezen. Daarom is het voor een aanvaller zeer effectief om deze strategie als eerste toe te passen. Het Engelse woordenboek bevat ongeveer 500.000 woorden (wat door de hedendaagse hardware in nog geen seconde doorlopen kan worden). Naast ‘normale’ woordenboeken kunnen aanvallers ook zelf woordenboeken maken door bijvoorbeeld eerder gekraakte wachtwoorden toe te voegen of informatie van de website van het slachtoffer te gebruiken.

Top 10 gebruikte wachtwoorden uit de gelekte Rockyou.com database

C-2011-2-Smeets2-t01

Combinatiestrategie. Mocht de woordenboekstrategie niets of weinig hebben opgeleverd, dan past de aanvaller de combinatiestrategie toe. Dit kan hij doen door woorden uit het woordenboek te combineren met elkaar of met jaartallen, veelvoorkomende lettercombinaties, substitutie, etc. Met deze strategie wordt bijvoorbeeld niet alleen het wachtwoord ‘password’ getest, maar ook ‘password123’, ‘P@ssw0rd’, ‘myPassword’, etc. Een variant van deze strategie is de ‘fingerprint aanval’ waarbij aanvallers gebruikmaken van statistieken uit eerder gekraakte wachtwoorddatabases, zoals lengte, tekenfrequentie en patroongebruik.
Uitputtend zoeken. Wanneer de eerste twee strategieën niets opleveren, is uitputtend zoeken de laatste mogelijkheid. Deze strategie, ook wel ‘brute force’ genoemd, is de meest krachtige maar ook het meest tijdrovend doordat een aanvaller alle mogelijkheden gaat doorzoeken, bijvoorbeeld door te beginnen bij ‘a’ en door te gaan tot en met ‘zzzzzzzzz’. Als de aanvaller lang genoeg zoekt, zal hij met behulp van deze techniek alle wachtwoorden kunnen kraken.

Het grote nadeel van de derde methode is dat wanneer de aanvaller geen informatie voorhanden heeft over het specifieke wachtwoordbeleid van de te kraken database, hij geen aannames kan doen over de wachtwoorddistributie en als gevolg dus alle tekens en lengtes van wachtwoorden moet proberen. Omdat het aantal mogelijkheden exponentieel stijgt, is deze aanval al snel niet meer uitvoerbaar. Stel dat je wachtwoord bestaat uit acht tekens die willekeurig gekozen zijn uit een reeks van alle 94 printbare karakters (26 kleine letters, 26 hoofdletters, tien cijfers en 32 speciale tekens) en dat deze versleuteld is met het NTLM (Windows) wachtwoordschema. Als een wachtwoord uit acht karakters bestaat dan zijn er ongeveer zes biljard mogelijke wachtwoordcombinaties die dienen te worden berekend (94^8≈ zes biljard). Een traditionele processor kan ongeveer twee miljoen wachtwoorden in NTLM-formaat per seconde proberen. Het zal deze computer meer dan tachtig jaar kosten om alle mogelijkheden van acht tekens te proberen. Grafische kaarten kunnen dit proces echter dusdanig versnellen dat eenzelfde wachtwoord binnen afzienbare tijd wordt gekraakt.

Waarom grafische kaarten?

Grafische kaarten bestaan al meer dan tien jaar en toch worden ze pas sinds kort gebruikt om wachtwoorden te kraken. Dit heeft drie redenen. Ten eerste neemt de vraag naar steeds mooier en realistischer ogende computerspellen toe, waardoor de rekenkracht van grafische kaarten ook moet toenemen. Ten tweede vindt er een verschuiving van focus plaats: waar vroeger grafische kaarten alleen werden gebruikt voor grafische doeleinden, het berekenen van individuele pixels op je beeldscherm, kunnen ze tegenwoordig ook gebruikt worden voor meer algemene taken. De producenten van grafische kaarten bieden nu ondersteuning voor andere operaties dan pixelberekeningen, zoals het rekenen met gehele getallen, wat het mogelijk maakt om cryptografische berekeningen te doen. Een andere trend die het mogelijk maakt om algemene taken op GPU’s uit te voeren, is de komst van gebruiksvriendelijke programmeerinterfaces. Deze bieden ook voor niet-grafische programmeurs kansen om de rekenkracht van grafische kaarten te benutten. Het grote verschil met de traditionele CPU is dat grafische kaarten geschikt zijn voor het doen van veel dezelfde parallelle berekeningen. Dit komt doordat dergelijke kaarten beschikken over honderden tot duizenden kleine ‘cores’ (miniprocessors), dit in tegenstelling tot een traditionele processor, die maar één tot vier cores heeft (zie figuur 2). Wel bestaat er een groot verschil in de architectuur: daar waar de cores van een CPU onafhankelijk van elkaar verschillende soorten berekeningen kunnen doen, moeten de cores van een grafische kaart op ieder moment dezelfde soort berekening doen (hoewel ze deze berekeningen wel op verschillende data kunnen uitvoeren). Hierdoor zijn niet alle (wiskundige) toepassingen geschikt om op een grafische kaart geïmplementeerd en uitgevoerd te worden.

C-2011-2-Smeets2-02

Figuur 2. Verschil in architectuur tussen grafische kaart (GPU) en normale processor (CPU). De groene ALU’s zijn de rekeneenheden, ook wel cores genoemd (bron: [Nvid10]).

Wachtwoorden kraken is een toepassing die juist wel erg geschikt is om geïmplementeerd te worden op een grafische kaart. Dit komt doordat tijdens het kraken iedere core dezelfde soort taak moet uitvoeren (namelijk het versleutelen van een wachtwoord en deze versleuteling vergelijken met de te kraken versleuteling), maar wel op verschillende data. Bijvoorbeeld core 1 versleutelt wachtwoord ‘aaaa’, core 2 versleutelt wachtwoord ‘aaab’, etc. De cores hoeven onderling niet samen te werken waardoor al snel een grote snelheidswinst tegenover traditionele processors kan worden bereikt. Deze snelheidswinst verschilt per wachtwoordschema. In figuur 3 is te zien dat de snelheid bij het gebruik van wachtwoordschema MD5-crypt tussen de dertig- en honderdmaal groter is dan die van een traditionele processor met dezelfde prijs.

C-2011-2-Smeets2-03

Figuur 3. Snelheid van MD5-crypt op verschillende hardwareplatformen (bron: [Spre11]).

Ontwikkelingen op het gebied van grafische kaarten

Het onderzoeksgebied van grafische kaarten is relatief jong en ontwikkelingen in dit gebied volgen elkaar dan ook erg snel op. In tegenstelling tot ontwikkelingen op het gebied van traditionele processors, waar men tegen fysieke limieten aanloopt zoals maximale processorsnelheid en schaalbaarheid, bestaat er nog een significante rek in de kracht van grafische kaarten. Gedreven door hevige concurrentie tussen de twee voornaamste producenten van grafische kaarten, Nvidia en ATI, worden gemiddeld ieder kwartaal nieuwe en beduidend snellere producten gelanceerd. Mede hierdoor worden ‘high-end’ kaarten snel goedkoper en toegankelijk voor het grote publiek.

De komst van gebruiksvriendelijke programmeerinterfaces zorgt ervoor dat programmeurs snel en makkelijk de calculaties kunnen verdelen over meerdere grafische kaarten. Dit zorgt ervoor dat de schaalbaarheid van implementaties enorm toeneemt. Hierdoor kan de gehele rekenkracht van een traditioneel rekencentrum worden geëvenaard met slechts een paar grafische kaarten.

Invloed op het wachtwoordbeleid

Wat betekent al deze rekenkracht van grafische kaarten nou voor de veiligheid van wachtwoorden? In figuur 4 wordt de kraaksnelheid van één grafische kaart vergeleken met de kraaksnelheid van één traditionele processor in dezelfde prijsklasse. De figuur laat zien hoeveel procent van de wachtwoorden in de gelekte Rockyou.com database[De Rockyou.com database is eind 2009 gehackt via een zogenoemde ‘SQL-injection’. De wachtwoorden van de 32 miljoen gebruikers waren niet versleuteld opgeslagen en zijn een uiterst waardevolle bron van informatie voor de hedendaagse wachtwoordstatistiek omdat het hier echte wachtwoorden van eindgebruikers betrof.] gekraakt kan worden in een bepaalde tijd als ze met het Windows NTLM-wachtwoordschema versleuteld zijn. Het blijkt dat grafische kaarten ongeveer twintig tot dertig procentpunt meer wachtwoorden kunnen kraken in dezelfde tijd.

C-2011-2-Smeets2-04

Figuur 4. De invloed van grafische kaarten op het kraken van de gelekte Rockyou.com database met 14 miljoen van de in totaal 32 miljoen gelekte wachtwoorden (bron: [Spre11]).

Het is al langer bekend dat gebruikers niet altijd in staat zijn om sterke wachtwoorden te genereren. Daarom implementeren veel organisaties een wachtwoordbeleid dat minimumeisen stelt aan de wachtwoordsterkte. Een voorbeeld van dergelijk beleid is het volgende:

Wachtwoorden hebben een minimumlengte van acht karakters.
Wachtwoorden bevatten ten minste één kleine letter, één hoofdletter, één cijfer en één speciaal teken.
Wachtwoorden dienen iedere vier maanden te worden gewijzigd.

Dit beleid zorgt ervoor dat er ten minste 94⁸ ≈ zes biljard mogelijkheden zijn waaruit gebruikers (en dus ook aanvallers) kunnen kiezen. Zoals eerder beschreven doet een traditionele processor er tachtig jaar over om al deze mogelijkheden af te lopen. Maar het programma OclHashcat[Voor meer informatie zie http://hashcat.net/oclhashcat/. ] kan in combinatie met een moderne grafische kaart van ATI meer dan 14 miljard mogelijkheden per seconde proberen. Dit zorgt ervoor dat alle wachtwoorden van acht karakters, versleuteld met het binnen Windows-domeinen veelgebruikte NTLM, binnen vijf dagen gekraakt kunnen worden. De buurjongen die een spelcomputer heeft met meerdere grafische kaarten, beschikt dan eigenlijk over een supercomputer. Gelet op de investeringen en ontwikkelingen op het gebied van grafische kaarten zal een aanvaller die wat meer te besteden heeft dan de buurjongen, in de nabije toekomst ook wachtwoorden van negen of tien karakters kunnen kraken.

Oplossingen

De beste oplossing voor dit probleem zou bereikt kunnen worden als gebruikers meer willekeurige, maar vooral ook langere wachtwoorden zouden kiezen. Een wachtwoord van twaalf karakters zal niet in de nabije toekomst zomaar gekraakt kunnen worden. Hoewel een goed wachtwoordbeleid hierbij kan helpen, is het aangetoond dat gebruikers moeite hebben met het onthouden van lange wachtwoorden. Laat staan wanneer ze voor elke service een apart wachtwoord moeten onthouden, wat zal leiden tot een vermenigvuldiging van het aantal post-it’s op beeldschermen en werkplekken.

Een mogelijkheid die uitkomst biedt voor gebruikers zijn tools voor het beheren van wachtwoorden, die random wachtwoorden kunnen genereren en aan de gebruikerskant versleuteld kunnen opslaan. Een gebruiker hoeft dan alleen nog maar één sterk wachtwoord te onthouden dat toegang biedt tot al zijn andere wachtwoorden. Een nadeel van deze methode is dat de gebruiker altijd het versleutelde bestand paraat moet hebben om gebruik te maken van services en internetdiensten. Even snel je e-mail bekijken bij een vriend kan nu niet meer zonder je persoonlijke wachtwoorddatabase.

Het kiezen van een sterk wachtwoord

Het is vooral de lengte van een wachtwoord die zorgt voor de sterkte. Het is daarom aan te raden een wachtwoord te kiezen dat zeker meer dan tien karakters bevat. Het wachtwoord wordt nog sterker wanneer het speciale tekens en cijfers bevat. Dergelijke wachtwoorden zijn erg moeilijk te onthouden. Een techniek die je helpt bij het genereren van je wachtwoord is de ‘mnemonic phrase’: kies een makkelijk te onthouden zin en neem van de woorden steeds de eerste of tweede letter. Het veiligste is een persoonlijke zin te kiezen en niet een die op het internet of in films te vinden is. Een voorbeeld van een mnemonic phrase is de volgende zin: “Mijn zus Debby heeft 3 honden: Max, Boris en Klaus”. Het afgeleide wachtwoord is dan: ‘MzDh3h:M,B&K’. Dit wachtwoord bevat twaalf karakters, met hoofdletters, kleine letters, cijfers en speciale tekens. Dit is zelfs voor een verzameling van grafische kaarten niet zomaar te achterhalen.

Let er tevens op dat u niet overal hetzelfde wachtwoord gebruikt. Het zou vervelend zijn als het gekraakte wachtwoord van uw account bij een webshop ertoe leidt dat een aanvaller ook toegang heeft tot uw internetbankierenomgeving.

Ook wordt het afgeraden opeenvolgende wachtwoorden te kiezen. Mocht een aanvaller onverhoopt uw wachtwoord ‘Wachtwoord!01’ kraken maar dit niet kunnen misbruiken omdat het is verlopen, dan begrijpt u vast dat de aanvaller zal proberen of u niet misschien ‘Wachtwoord!02’ als huidig wachtwoord heeft.

Oplossingen moeten niet alleen aan de gebruikerskant gezocht worden. De volgende oplossingen kunnen geïmplementeerd worden aan de serverkant.

Betere wachtwoordschema’s. Zoals eerder beschreven, kunnen wachtwoorden versleuteld met het NTLM-schema erg snel worden gekraakt. Dit geldt niet voor wachtwoorden die versleuteld worden met sterkere wachtwoordschema’s zoals ‘SHA-crypt’ of de meer generieke techniek ‘Password-Based Key Derivation Function’ (PBKDF). Deze wachtwoordschema’s maken gebruik van een speciale techniek die de complexiteit van de berekeningen verhoogt. Het is dan voor één gebruiker nog steeds mogelijk om het versleutelde wachtwoord te berekenen, maar voor een aanvaller, die veel mogelijkheden moet proberen, wordt het haast onmogelijk gemaakt. Een nadeel van deze techniek is dat men vooraf niet weet hoe complex de berekeningen moeten zijn. Dit is altijd afhankelijk van de op dat moment geldende hardwarenormen en daarom blijft deze oplossing een kat-en-muisspelletje tussen de ontwerpers van wachtwoordschema’s en aanvallers. Periodiek kiezen voor betere wachtwoordschema’s is dan ook het advies.
Multi-factor authenticatie. Een oplossing die structureel verbetering brengt, is het authenticatieproces uitvoeren met meerdere factoren. Dit betekent dat een gebruiker tijdens authenticatie niet alleen iets verstrekt wat hij weet, zoals een wachtwoord of pincode, maar ook iets wat hij heeft, zoals een fysieke token of smartcard, of wat hij is, zoals een vingerafdruk. Deze oplossing maakt wachtwoordsterkte minder relevant, omdat een aanvaller twee of meer factoren in handen moet zien te krijgen om zich toegang te verschaffen. Nadelen van deze oplossing zijn de implementatiekosten en het beheer. Daar komt nog bij dat niet iedere gebruiker akkoord gaat met het gebruik en de opslag van zijn of haar biometrische gegevens.
Vaker wisselen van wachtwoord. Als een aanvaller zes maanden nodig heeft voor het kraken van een wachtwoord, maar de gebruiker het wachtwoord al na drie maanden dient te wijzigen, dan kan de aanvaller het wel kraken maar is het nutteloos voor de aanval. Vaak wisselen is dan ook het advies. Maar let bij het wisselen er wel op dat de wachtwoorden geen logisch vervolg van elkaar zijn (zie ook kader ‘Het kiezen van een sterk wachtwoord’).

Conclusie

Eens in de zoveel jaar zijn er doorbraken in de wereld van computerkracht. De huidige doorbraak in de kracht van grafische kaarten in (spel)computers zorgt niet alleen voor oogverblindend mooie spelletjes, maar ook voor een doorbraak in de snelheid waarmee wachtwoorden kunnen worden gekraakt. Hackers maken hier dankbaar gebruik van en in de nabije toekomst heeft dit impact op de veiligheid van uw wachtwoorden en daarmee van uw IT-omgeving. Dit zorgt ervoor dat traditionele opvattingen over een sterk wachtwoord (bijvoorbeeld minimaal acht karakters met hoofd- en kleine letters, cijfers en speciale tekens) niet meer geheel toereikend zijn. Hoewel een aantal maatregelen is te nemen aan de kant van de technische configuratie van uw IT-omgeving zullen we hoe dan ook nog een flinke tijd met wachtwoorden werken. De voornaamste aanbeveling is dan toch ook wel om het gebruik van moeilijkere en vooral langere wachtwoorden (minimaal tien karakters) af te dwingen. Daarmee bent u in ieder geval de komende tijd een stuk beter voorbereid op aanvallen van hackers en zelfs van uw buurjongen.

Literatuur

[Burr04] W.E. Burr, D.F. Dodson and W. T. Polk, Electronic authentication guideline, NIST Special Publication, 800:63, 2004.

[Nvid10] Compute Unified Device Architecture Programming Guide, Technical report, Nvidia Corporation, August 2010.

[Spre11] Martijn Sprengers, Gpu-based password cracking: On the security of password hashing schemes regarding advances in graphics processing units, Master’s thesis, Radboud University Nijmegen, January 2011.

[Yan04] J. Yan, A. Blackwell, R. Anderson and A. Grant, Password memorability and security: Empirical results, Security & Privacy, IEEE, 2(5):25–31, 2004.

Trends in de beveiliging van mobiele apparaten

De introductie van een nieuwe generatie mobiele apparaten, onder aanvoering van Apple (met de iPhone) en Google (met het Android-systeem), heeft het gebruik van mobiele telefoons binnen en buiten het bedrijfsleven ingrijpend veranderd: nieuw, modern, mooi vormgegeven, altijd verbonden met het internet en legio Apps voor allerlei functies. Bovendien lijkt de iPad van Apple het succes van de iPhone te herhalen en is deze vinding bezig een breed segment van de zakelijke markt te veroveren, waardoor ook binnen het bedrijfsleven een lucratieve markt ontstaat voor tablet-pc’s.

Het gebruik van deze nieuwe mobiele apparaten past geheel bij de huidige tijd en het is dan ook niet meer dan logisch dat deze apparaten een weg vinden naar de bedrijfsomgevingen. Productieverhogend en communicatie vergemakkelijkend zijn de positieve effecten van deze ontwikkeling. Maar er kleven ook risico’s aan. En doordat de fabrikanten maar wat graag aangeven dat hun producten op-en-top veilig kunnen zijn, zijn deze risico’s zijn niet altijd even duidelijk. In dit artikel zal ik de voornaamste verschillen met traditionele apparaten bespreken, aanstippen waar de beveiligingsrisico’s liggen en oplossingen aandragen voor de aanpak van deze risico’s.

Inleiding

Het ontwerp van deze nieuwe generatie mobiele apparaten verschilt op twee belangrijke punten fundamenteel van dat van de vorige generatie ‘smart phones’. Ten eerste beschikken zij over een veel grotere functionaliteit en ten tweede is er sprake van zogenaamde consumerization van dergelijke apparaten.

In het onderstaande wordt uitgebreid ingegaan op deze twee punten van verschil. Vervolgens komt aan de orde met welke nieuwe beveiligingsrisico’s rekening gehouden dient te worden en meer in detail de achtergrond van deze risico’s die ontstaan in de basissystemen van deze apparaten maar ook in de Apps. Als laatste wordt besproken welke set aan beveiligingsmaatregelen bestaat om de risico’s te beperken.

Veel grotere functionaliteit

Dankzij de voortdurende verbetering van de hardware hebben deze apparaten nu enorme rekenkracht, vergelijkbaar met die van desktopcomputers van enkele jaren geleden. Hierdoor hoeven geen unieke besturingssystemen[Een besturingssysteem, in het Engels operating system, is het geheel van programmatuur dat in het geheugen van de computer wordt geladen na het opstarten. Deze programma’s bieden samen de functionaliteit om andere programma’s uit te voeren.] ontwikkeld te worden; producenten kunnen hun apparaten baseren op bestaande besturingsystemen voor pc’s. Het iOS-systeem van Apple is afgeleid van haar Mac OS X-besturingssysteem voor het Macintosh-platform. Het Android-besturingssysteem van Google is afgeleid van het open source besturingssysteem Linux. Er zijn wel enkele aanpassingen gemaakt aan het onderliggende besturingssysteem voor verbeterd mobiel gebruik. Deze aanpassingen zijn vooral gericht op het efficiënter omgaan met stroom om een vermindering van het batterijverbruik te realiseren, het verwijderen van functionaliteiten die op een mobiele telefoon geen nut hebben (zoals het ondersteunen van randapparatuur) en de toepassing van gebruikersinterfaces die met de vingers bediend kunnen worden in plaats van met een muis. Desondanks zijn de kern van het besturingssysteem en alle bijbehorende functionaliteit behouden, waardoor er op mobiele telefoons een enorm scala aan applicaties gebruikt kan worden. Hierdoor kun je dezelfde browser, Google Maps, chat-applicatie en applicaties voor het delen van bestanden[Dropbox, een programma om bestanden tussen apparaten te delen, http://www.dropbox.com/iphoneapp .] gebruiken als op je desktop.

Deze integratie van besturingssystemen werpt nu ook z’n vruchten af voor de desktop-pc’s. Functionaliteiten die groot zijn geworden op het mobiele platform vinden hun weg naar de desktop-pc’s. Denk hierbij aan de App store die Apple ook aanbiedt voor Mac OS X.[Mac Store, een App Store voor Mac OS X http://www.apple.com/nl/mac/app-store/.] Maar bijvoorbeeld ook aan de voortgaande optimalisatie van webbrowsers op mobiele apparaten die zorgt voor snellere versies van dezelfde webbrowsers op de desktop-pc’s. Er vindt dus een wederzijdse beïnvloeding plaats.

Tevens is, dankzij de vooruitgang in de mobiele connectiviteit (denk aan 3G-technieken zoals UMTS), de internetverbinding van deze apparaten effectiever en efficiënter geworden en zijn ook andere interactieve verbindingen zoals GPS en draadloos netwerken mogelijk. Vaak staan de applicaties op deze mobiele apparaten dan ook continu in verbinding met het internet. Zo kun je er bijvoorbeeld voor kiezen om je muziek niet langer op je mobieltje op te slaan maar uit de cloud te streamen.[Spotify, een programma om streaming muziek te luisteren http://www.spotify.com/int/blog/archives/2009/07/27/spotify-for-iphone/.]

De ontwikkelingen staan dus zeker niet stil. En de mobiele apparaten ontpoppen zich dan ook tot volwaardige mobiele computers waarmee de meest voor de hand liggende taken kunnen worden uitgevoerd.

‘Consumerization’ van de mobiele apparaten

De scheiding tussen zakelijk en privé wordt minder strikt en de technische middelen die deze apparaten bieden, scheppen een omgeving waarbij dit nog meer wordt gefaciliteerd. De nieuwe generatie mobiele apparaten is namelijk ontworpen met het oog op de individuele consument in plaats van de zakelijke markt. Bovendien zijn de producenten en leveranciers er bijzonder goed in geslaagd om deze apparaten aan te prijzen als ‘must haves’.

Het hoeft daarom geen verbazing te wekken dat veel werknemers liever gebruikmaken van hun eigen mobieltje, dat meer mogelijkheden heeft en er leuker uitziet, dan van de telefoon van de zaak. In plaats van één apparaat voor hun zakelijke en een ander voor hun privécommunicatie, gebruiken ze liever voor allebei het nieuwste en meest gebruiksvriendelijke apparaat. Dat dit vaak het apparaat is dat is bedoeld voor de reguliere consument en dat deze apparatuur zo ook in de bedrijfsomgeving belandt, noemen we ‘consumerization’. Als gevolg hiervan raakt de privécommunicatie van de gebruiker, zoals interactie op sociale media, privégesprekken, sms’jes en web browsing, verweven met bedrijfsinformatie zoals zakelijke e-mails, documenten (ontvangen, aanpassen en versturen) en telefoonverkeer.

Nieuwe mogelijkheden gaan gepaard met nieuwe risico’s

Deze nieuwe mobiele apparaten kunnen dus meer en we gebruiken ze daarom steeds vaker, ook zakelijk. Is dat erg? De nieuwe mogelijkheden van deze apparaten brengen aanzienlijke nieuwe veiligheidsrisico’s met zich mee, vooral op het vlak van de technische beveiliging en vertrouwelijkheid van gevoelige persoonlijke en bedrijfsinformatie. Doordat deze apparaten zijn gebaseerd op standaardbesturingssystemen en een enorm scala aan functionaliteiten bevatten, staan ze onvermijdelijk bloot aan een groter aantal risico’s. De producenten van deze apparaten, en wellicht ook anderen die de risico’s willen beperken, moeten zich nog aanpassen aan deze gewijzigde situatie. Zo is het moeilijk om informatie over een foutief SSL-certificaat[SSL-certificaat: een versleutelmechanisme gebruikt voor communicatie over internet om de identiteit van de andere partij vast te stellen en om de versleuteling van datatransport te initiëren. Websites zoals die van uw bank gebruiken vaak SSL over HTTP, ook wel te herkennen aan HTTPS:// in de adresbalk en een klein slotje gepresenteerd door uw browser.] van een website te krijgen op zo’n klein scherm (zie ook de figuren 1 en 2). Op een traditionele computer is deze informatie wel goed toegankelijk.

C-2011-2-Smeets1-01

Figuur 1. Het certificaat van een e-mailserver klopt niet volgens de iPhone en springt in beeld voor de eindgebruiker. We kunnen dit certificaat weigeren en als gevolg geen e-mail ontvangen, direct accepteren en mogelijk onderwerp zijn van een aanval, of we kunnen meer details bekijken over de uitgever van het certificaat.

C-2011-2-Smeets1-02

Figuur 2. Details over de uitgever van het certificaat. Kunnen we met deze beperkte informatie goed beoordelen of dit een geldig certificaat is?

Maar naast wijzigingen met betrekking tot bestaande beveiligingsmaatregelen hebben de fabrikanten ook te maken met technieken zoals SMS, 3G-communicatietechnieken en GPS die voor hen nieuw zijn. Daardoor zijn de beveiligingsmaatregelen ten aanzien van de gegevens die op deze apparaten worden opgeslagen of verstuurd, nog niet volledig uitontwikkeld en getoetst {REF naar 13, Collin Mulliner et al}.[Collin Mulliner en Charlie Miller, augustus 2009, Fuzzing the Phone in your Phone (Black Hat USA, 2009).] Bovendien bestaat bij deze apparaten een grotere kans op cyberaanvallen omdat ze continu in verbinding staan met het internet.

Problemen met de basisveiligheid van de mobiele apparaten

Een goed voorbeeld van een niet volledig uitontwikkelde beveiligingsmaatregel is de toepassing van encryptie op de iPhone, wat de suggestie wekt dat de opgeslagen gegevens zijn versleuteld. De telefoon hoeft echter alleen maar te worden aangezet om de gegevens te ontsleutelen. Een oneigenlijke gebruiker hoeft dan slechts het wachtwoord (ook wel pincode of passcode genoemd) te kennen om toegang te krijgen tot het toestel. Echter, als men dit invoerscherm van het wachtwoord kan omzeilen (zoals tweemaal eerder mogelijk was op de iPhone[iPhone passcode fout augustus 2008, http://www.zdnet.com/blog/security/iphone-passcode-lock-rendered-useless/1809; iPhone passcode fout oktober 2010, http://www.zdnet.com/blog/security/iphone-passcode-lock-bypass-vulnerability-again/7544 .]) of op een andere manier toegang kan krijgen tot het toestel, bijvoorbeeld door zwakheid uitgebuit via het netwerk, dan is de informatie op de telefoon direct toegankelijk. Vergelijk het met een laptop uitgerust met ‘full-disk’ encryptie waarbij de laptop geheel zelfstandig kan opstarten. De eerste keer dat een eindgebruiker dan een wachtwoord hoeft in te voeren is pas bij het Windows-inlogscherm. Op dat moment is het besturingssysteem al volledig actief en er zijn dan ook al legio aanvallen mogelijk.

Om iets te doen aan dit probleem heeft de leverancier extra encryptie ingebouwd voor de versleuteling van e-mail, contactpersonen en agendagegevens.[Data Protection functionaliteit op iOS, http://support.apple.com/kb/HT4175.] Maar dit omvat lang niet alle gegevens op de telefoon en ook deze tweede encryptie is niet volledig effectief. Als resultaat kunnen sommige ‘dubbel versleutelde’ gegevens toch gelezen worden door een oneigenlijke gebruiker.

Bovendien kan deze oneigenlijke gebruiker (die het wachtwoord niet kent) door middel van ‘jailbreaking’ de door de leverancier ingebouwde sloten verwijderen. Hiermee is volledige toegang tot het apparaat verkregen en kan de oneigenlijke gebruiker data lezen en aanpassen. Jailbreaking is heel eenvoudig; men kan op de iPhone surfen naar JailBreakMe,[http://jailbreakme.com, een website die bepaalde versies van iPhone kan ‘jailbreaken’ via de webbrowser van de iPhone.] of de iPhone aansluiten op een computer en daarop applicaties draaien die vrijelijk beschikbaar zijn en het jailbreaken tot een koud kunstje maken.[Uitgebreid artikel over jailbreaken, http://www.iphoneclub.nl/58620/jailbreaken-en-unlocken-hoe-moet-dat-eigenlijk/.] De ‘jail’ kan op een laag niveau verwijderd worden vanwege kritische zwakheden in onderdelen van de iOS-software. Bovendien is jailbreaking in de Verenigde Staten nu legaal dankzij een recente wijziging in de copyrightwetgeving (deze wetswijziging is opgenomen in de Digital Millennium Copyright Act). Fabrikanten verwijderen dan ook de detectie van jailbreaks uit hun besturingssysteem.[Webwereld-artikel over detectie van jailbreak, http://webwereld.nl/nieuws/68092/apple-zet-iphone-jailbreak-detectie-uit.html.]

Het zakelijk gebruik van privételefoons maakt het lastiger om naleving af te dwingen van bedrijfsbeleid omtrent bedrijfscommunicatie en de vertrouwelijkheid en beveiliging van informatie. Het betreft immers een privételefoon. Maar een samensmelting van privé- en zakelijke data op het mobiele apparaat is dan wel een feit. Op de telefoons kunnen bijvoorbeeld wachtwoorden zijn opgeslagen waarmee men op websites inlogt voor privégebruik, maar ook voor zakelijk gebruik. Onderzoekers hebben al aangetoond dat door een jailbreak toe te passen volledige toegang tot wachtwoorden kan worden verkregen zonder voorkennis te hebben van het toestel.[Volledige toegang tot wachtwoorden door jailbreak, http://www.sit.fraunhofer.de/en/presse/Lost_iPhone.jsp.] Bent u als eigenaar van de IT-omgeving blij als inloggegevens tot deze IT-omgeving op straat belanden doordat een medewerker zijn privételefoon is verloren?

Oplossingen hiertoe komen later in dit artikel aan bod, maar het moge duidelijk zijn dat de oplossingen niet louter in technische maatregelen dienen te worden gezocht. Denk bijvoorbeeld aan een beleidsmatige maatregel dat diefstal van een mobiel apparaat direct dient te worden gemeld, zodat het bedrijf een actie tot ‘remote-wipe’ kan uitvoeren op de iPhone. Dat hierbij ook privédata worden verwijderd mag geen discussie meer zijn doordat de eindgebruiker eerder akkoord is gegaan met het beleid.

Problemen met Apps op de mobiele apparaten

Naast de basisveiligheid van de mobiele apparaten zelf dient ook nog rekening gehouden te worden met de factor Apps. Het is voor de gebruiker van de telefoon mogelijk duizenden Apps te installeren, ieder met z’n eigen functionaliteit, zoals het handig opslaan van documenten en notities in de cloud zodat de gebruiker er ook via andere computers nog bij kan. Daarnaast kunnen bedrijven zelf ook Apps maken om diensten aan te bieden aan hun klanten. Maar in die Apps kunnen ook beveiligingsfouten sluipen, zoals een gerenommeerde Amerikaanse bank onlangs ondervond.[Bank applicatie slaat transactie gegevens en inlogcodes op van klanten http://online.wsj.com/article/SB10001424052748703700904575391273536355324.html.] In een door haar ontwikkelde App leidden fouten ertoe dat gegevens opgeslagen bleven op de telefoon. Hierdoor kwamen gegevens vrij die toegang gaven tot rekeningoverzichten en waarmee geld kon worden overgemaakt.

Het komt erop neer dat op deze mobiele apparaten in veel meer bestanden en folders (niet alleen in e-mails en de agenda) erg veel gegevens worden opgeslagen. Hoewel de eindgebruiker wellicht niet direct toegang kan krijgen tot al deze bestanden doordat de standaard-gebruikersinterface dit niet laat zien, worden de gegevens wel opgeslagen. En daar waar data worden opgeslagen, kunnen zij potentieel weglekken. Dit kan leiden tot het weglekken van bedrijfsgegevens maar ook het in gevaar brengen van de privacy van de gebruiker. Twee recente voorbeelden: elke iPhone heeft bijvoorbeeld een uniek nummer, de UUID. Onderzoekers hebben aangetoond dat diverse Apps dit UUID, de geografische locatie van de telefoon en informatie uit het adresboek gebruiken en opslaan om statistieken over de gebruikers van deze Apps te verzamelen,[Eric Smith, oktober 2010, iPhone Applications & Privacy Issues: An Analysis of Application Transmission of iPhone Unique Device Identifiers (UDIDs).] zonder dat de gebruikers hiervan volledig op de hoogte zijn. Het tweede voorbeeld betreft technieken zoals triangulatie van GSM-masten die de iPhone hanteert om te weten waar in de wereld de telefoon zich bevindt. Onderzoekers hebben duidelijk gemaakt dat door middel van een simpel programmaatje het mogelijk is – met een nauwkeurigheid van enkele honderden meters – de fysieke locatie van de telefoon te illustreren.[iPhone location tracker applicatie, April 2011, http://www.vulnerabilitydatabase.com/2011/04/iphone-tracker-map-your-iphone-stored-information/.] De iPhone slaat dit lokaal op in een database en verstuurt dit periodiek naar de leverancier. Apple heeft de fout erkend en hier ook al op gereageerd.[Apple’s antwoord over opslag van locatiebepalingen, April 2011, http://www.apple.com/pr/library/2011/04/27location_qa.html.]

Samenvattend bestaan er ernstige zorgen of de huidige beveiligingsmaatregelen voor mobiele apparaten afdoende zijn om de hierboven genoemde risico’s te minimaliseren.

Hoe kan men dit aanpakken, en wat is al in gang gezet?

Momenteel bieden producenten van mobiele telefoons nog geen volledige beveiligingsoplossingen. Hierdoor is er ruimte in de markt voor andere leveranciers die dergelijke oplossingen aan bedrijven leveren. De oplossingen variëren van het creëren van meer maatregelen om de apparaten onder controle te houden tot het inbouwen van ‘encrypted containers’ voor de opslag van bedrijfsgegevens op het apparaat. Deze oplossingen maken het aanzienlijk moeilijker voor een oneigenlijke gebruiker om toegang tot gegevens te krijgen. Maar het oorspronkelijke probleem blijft: als de telefoon zelf niet is beveiligd, kunnen ook deze oplossingen geen volledige veiligheid bieden. Ze kunnen het echter wel heel moeilijk maken voor een aanvaller, dus er is hoop.

De markt voor deze oplossingen is pas recent opgekomen en dus volop in ontwikkeling en daardoor nog niet volwassen. Het is daarom niet reëel om nu al volledig uitontwikkelde oplossingen te verwachten. Het gaat er nu om te erkennen dat de grotere mogelijkheden van de nieuwe generatie mobiele apparaten gepaard gaan met andere en grotere risico’s en meer dan ooit te waken over kritische bedrijfsinformatie. Totdat producenten en leveranciers volledig effectieve technische beveiligingsmaatregelen op de markt brengen, moeten eindgebruikers bewust gemaakt worden van de risico’s van deze apparaten. Daarnaast dient erop toegezien te worden dat op de apparaten die verbinding maken met zakelijke IT-omgevingen de beschikbare beveiligingsmaatregelen worden gebruikt. Deze maatregelen vormen slechts een eerste verdedigingslinie. Onthoud daarbij dat het om een samenwerking gaat van technische en organisatorische maatregelen.

Gebruik deze eerste verdedigingslinie wel ten volle. Implementeer dus een strikt wachtwoordbeleid, sta alleen apparaten met een vorm van encryptie toe, implementeer een effectief proces dat verloren apparaten ontkoppelt van de IT-omgeving, zorg dat de gebruikers altijd de laatste updates installeren en informeer gebruikers voortdurend over de gevaren.

Verder dienen verstandige keuzes gemaakt te worden voor technische oplossingen waarmee de IT-afdeling middelen heeft om de uitdagingen aan te gaan en het gebruik van deze apparaten in lijn kan brengen met richtlijnen die volledig aansluiten op beleid omtrent de verwerking van bedrijfsinformatie.

Conclusie

Risico’s in gebruik van deze mobiele apparaten bestaan, maar de wil van de eindgebruikers om deze mobiele apparaten te gebruiken bestaat net zo goed. Helaas zijn de maatregelen nog niet volwassen genoeg voor een simpele en kant-en-klare oplossing. En daar zit de crux. Alleen e-mailen via webmail toestaan, of kan lokale e-mail ook? Alleen het gebruik toestaan mits een aantal technische maatregelen is ingevoerd op het apparaat zelf, of is de standaard iPhone veilig genoeg? Mogen alle websites worden bezocht met het mobiele apparaat, of dient er iets gefilterd te worden? Welke Apps slaan geen vertrouwelijke data op in de cloud en kunnen we veilig gebruiken? Dient iTunes nu ook te worden ondersteund op de bedrijfs-pc’s? En hoe gaan we om met de back-ups die iTunes maakt op de privé-pc’s, en wat zit er precies aan zakelijke data in die back-ups? Hoe krijgen we als IT-afdeling inzage in het gebruik van het mobiele apparaat? En wat is het risico van het ophalen van e-mail via een onbeveiligd draadloos netwerk? Hoe reageren we snel en juist op het verlies of diefstal van een mobiel apparaat? Allemaal vragen waar passende antwoorden voor zijn, maar waarbij de antwoorden afhangen van de reeds bestaande beveiligingsmaatregelen in het bedrijf. Het is dan ook zaak een gedegen analyse te maken van de maatregelen die men dient te treffen per bedrijfsomgeving.

Interessante ontwikkeling, deze nieuwe mobiele apparaten. Maar werk aan de winkel voor de informatiebeveiliger!

Social engineering: de kunst van het misleiden

In een typische penetratietest (hacker test) wordt geprobeerd ongeautoriseerd toegang te krijgen tot systemen of data door misbruik te maken van technische kwetsbaarheden. De ‘zwakste schakel’ in de informatiebeveiliging blijft in een dergelijke test buiten schot, namelijk de mens. In toenemende mate blijkt deze ‘schakel’ het doelwit van aanvallers te worden. In de media wordt een groot aantal incidenten gerapporteerd waarbij deze aanvallen een rol spelen (security.nl). Reden genoeg om in het kader van een audit of een informatiebeveiligingsonderzoek ook deze ‘schakel’ aan een test te onderwerpen. Dit artikel beschrijft hoe dit ‘hacken van mensen’, ook wel ‘social engineering’ genoemd, in zijn werk gaat, gaat in op enkele praktijkvoorbeelden en behandelt maatregelen die tegen dergelijke aanvallen kunnen worden genomen.

Wat is een social-engineering test?

Door KPMG IT Advisory worden voor een groot aantal klanten social-engineering opdrachten uitgevoerd. Bij een dergelijke test is het doel tweeledig:

de risico’s voor de onderzochte organisatie in kaart te brengen;
de medewerkers bewust maken van deze risico’s (training).

Tijdens de testen wordt geprobeerd medewerkers zo te manipuleren dat toegang wordt verkregen tot vertrouwelijke gegevens. Deze pogingen variëren van een ‘eenvoudige beltest’ waarbij wachtwoorden moeten worden ontfutseld en zogenaamde phishing-aanvallen (waarin gebruik wordt gemaakt van nep-e-mails of nep-websites), tot fysieke aanvallen waarbij undercover al dan niet met nagemaakte toegangspasjes het pand van een klant wordt betreden om vervolgens van binnenuit vertrouwelijke informatie te verzamelen. De bevindingen zijn over het algemeen opmerkelijk; ongeautoriseerde toegang tot kluizen in banken, beveiligde locaties van de overheid en tot in grote datacenters aan toe, om er maar een paar te noemen. In verschillende van deze gevallen wordt de opdracht gecombineerd met een penetratietest. Bij deze gecombineerde testen, ook wel aangeduid met red teaming (figuur 1), is over het algemeen de opdracht eerst ongeautoriseerd fysiek in het pand te komen, vervolgens van binnenuit de interne systemen te hacken, en weer ongezien mét vertrouwelijke gegevens het pand te verlaten.

C-2011-2-Paques-01

Figuur 1. Red teaming, testmethode waarbij verschillende aanvalstechnieken gecombineerd worden om een daadwerkelijke aanval te simuleren.

Het grote verschil tussen een penetratietest, waar je aanvallen echt kan ‘testen’ op systemen, en social-engineering testen is dat je bij de laatste over het algemeen maar één kans hebt. Er is geen ‘uitprobeerronde’; het moet in één keer goed. Als je verhaal niet geloofwaardig is, bestaat de kans met handboeien om afgevoerd te worden. De medewerkers van de organisatie waar de test wordt uitgevoerd zijn over het algemeen niet op de hoogte gebracht van de test. Veelal weten alleen enkele directieleden van de test en zelfs zij weten niet in alle gevallen wannéér de test precies zal worden uitgevoerd. Het is niet de bedoeling dat de beveiliging opeens extra gaat opletten bijvoorbeeld. Op deze manier kan een reëel beeld van de risico’s worden verkregen. Als gevolg hiervan zal beveiligingspersoneel ook geen halve maatregelen nemen wanneer je als ‘indringer’ wordt ontmaskerd (zeker niet wanneer je op dat moment een stapel vertrouwelijke interne documenten in bezit hebt).

Ingrediënten van een geslaagde aanval

Om een aanval te laten slagen zijn twee zaken van doorslaggevend belang: informatie en timing. Een gedegen voorbereiding is essentieel. Voorafgaand aan een onderzoek wordt dan ook zoveel mogelijk informatie over het doelwit verzameld. Niet alleen over de organisatie waar het om gaat (corporate homepage, Google maps, search engines, nieuwsgroepen, vacaturesites), maar ook over de medewerkers, hun hobby’s, woonplaats en contactgegevens (Facebook, Hyves, LinkedIn en dergelijke zijn erg nuttig). Daarna volgt veelal een aantal telefoontjes naar het algemene nummer en nummers van medewerkers voor zover deze via publiek beschikbare bronnen beschikbaar zijn. Bij grote organisaties zijn vaak reeksen telefoonnummers in gebruik. Op basis van bekende nummers wordt dan een aantal nummers in dezelfde reeks gebeld. Wanneer een medewerker opneemt, wordt aangegeven verkeerd verbonden te zijn en op zoek te zijn naar meneer X. Het goede nummer van meneer X evenals de naam en functie/afdeling van de gebelde persoon worden tevens zijdelings geverifieerd. Informatie die zo wordt verkregen kan weer gebruikt worden om nog meer informatie los te krijgen. Alle te vinden informatie is potentieel interessant. Voor een test op een streng beveiligd datacenter is wel eens twee maanden voor de test met een camera met 500mm lens van alle kanten het gebouw gefotografeerd om vast te stellen waar alle camera’s en ingangen waren, hoe de medewerkers gekleed waren, hoe laat ze naar huis gingen, etc. Op basis van deze informatie worden vervolgens de details van een aanvalsscenario bepaald. Als wie gaan we ons voordoen, hoe laat moeten we aankomen (bijvoorbeeld om mee te kunnen lopen met de ‘massa’), welke kleding kunnen we het beste aantrekken en welke route nemen we als we eenmaal ‘binnen’ zijn om zoveel mogelijk risico’s (camera’s en beveiligingsmensen) te omzeilen.

De timing van een aanval is tevens erg belangrijk. Het moment dat een geschikte medewerker zich aandient kan een kwestie van seconden zijn. Veelal is een medewerker nodig om langs een poort/hek/receptie of ander controlepunt te komen. Met kennis van het bovenstaande, een goed verhaal, het kunnen improviseren op onvoorziene situaties, gemakkelijk contacten kunnen leggen en af en toe stalen zenuwen kom je dan al een heel eind.

Op een gegeven moment leer je wat voor mensen je moet benaderen en welke je beter uit de weg kunt gaan. Secretaresses weten bijvoorbeeld vaak bijzonder goed wat er in een bedrijf speelt. Het kan heel waardevol zijn deze te benaderen, maar een goed en degelijk onderbouwd verhaal is wel een voorwaarde. Volledig improviseren is dan een soort Russische roulette. Praktijkvoorbeeld 1 beschrijft een test waarbij de te benaderen personen specifiek werden geselecteerd om de kans van slagen zo groot mogelijk te maken.

Praktijkvoorbeeld 1

Bij één van onze klanten voerden een collega en ik een geavanceerde phishing-aanval uit. Mijn collega had bij de ingang van het pand van de klant plaatsgenomen en vroeg selectief medewerkers die naar binnen gingen of deze deel wilden nemen aan een enquête over de invulling van een aankomende bedrijfsactiviteit. Bij de ‘selectie’ van medewerkers richtten we ons tot de jongere, vrouwelijke medewerkers om zoveel mogelijk de kans te beperken per ongeluk een IT-medewerker of managementlid aan te spreken. (Deze zouden het immers weten als er een ‘enquêtepagina’ bestond en daardoor de aanval mogelijk sneller doorgronden.) Ook hadden we vooraf de LinkedIn- en Facebook-profielen van sleutelpersonen in de organisatie bekeken om zo ‘risicopersonen’ te herkennen en te kunnen vermijden.

Onder de deelnemers zou dezelfde week nog een iPod Touch worden verloot. De medewerkers die wilden deelnemen kregen een gesloten enveloppe met daarin een brief die de actie uitlegde en een link naar een door ons opgezette (nep)internetpagina met daarop de enquête. Na inloggen kreeg de medewerker een tiental vragen te zien en konden aanvullend nog eigen suggesties worden opgegeven. Na versturen werd de medewerker hartelijk bedankt voor de deelname. Uiteraard waren wij in het geheel niet geïnteresseerd in alle ‘feestideeën’ van medewerkers, maar was het ons alleen om de inloggegevens van de medewerkers te doen. Ikzelf had om de hoek van de ingang positie ingenomen, zodat ik door de ramen aan de zijkant van de ingang in de gaten kon houden of er binnen iets verdachts gebeurde en via de portofoon direct mijn collega kon aangeven zich uit de voeten te maken indien dit nodig was. Tevens kon ik via mijn smartphone ‘live’ vaststellen dat inmiddels enkele gebruikers hun wachtwoord hadden ingetoetst op onze website en de test dus al succesvol was geweest. Na ongeveer 35 minuten verlieten we beiden in verschillende richtingen de locatie. We hadden bepaald dat dit zo ongeveer de tijdspanne was waarin in geval van detectie een opvolging zou kunnen plaatsvinden. In de nabespreking met de klant bleek later dat hooguit enkele minuten na ons vertrek twee gealarmeerde medewerkers naar buiten waren gekomen om opheldering te vragen.

Training van medewerkers

Belangrijk bij de test is ook het doel training van medewerkers niet uit het oog te verliezen. De aanvalsscenario’s dienen zo gekozen te worden dat de impact die medewerkers hiervan kunnen ondervinden tot het minimaal noodzakelijke beperkt wordt. Wij geven de opdrachtgever (voor zover dat mogelijk is) ook géén inzicht in welke medewerkers een rol hebben gespeeld in de testen en bevindingen. Gegevens worden geanonimiseerd en er wordt gerapporteerd over aantallen en de impact van de testresultaten. Het minst verstandige wat een opdrachtgever zou kunnen doen (en natuurlijk ook zeer onwenselijk, maar niet geheel ondenkelijk) is het nemen van disciplinaire maatregelen tegen de betreffende medewerkers. Het effect hiervan is dat medewerkers wanneer ze daadwerkelijk ‘slachtoffer’ worden van een echte social-engineering aanval dit mogelijk niet zullen melden uit angst voor represailles en de organisatie de aanval niet of te laat zal opmerken met alle gevolgen van dien.

Een goede opvolging van een social-engineering test is om de resultaten terug te koppelen naar (alle) medewerkers zodat deze de test daadwerkelijk als een leermoment kunnen ervaren en daarmee (beter) voorbereid zijn tegen een ‘echte’ aanval. In de praktijk blijkt overigens het merendeel van niet-getrainde medewerkers gevoelig voor een social-engineering aanval en laten medewerkers van hoog tot laag in de organisatie zich misleiden.

Psychologische trucs

Hoewel het aanvalsscenario voor een test volledig wordt afgestemd op de situatie bij de klant en daarmee iedere keer verschillend is, is er een aantal psychologische principes of ‘trucs’ die hier de basis van zijn en iedere keer terugkomen:

Een band opbouwen, bijvoorbeeld door het benoemen van een gemeenschappelijk probleem of interesse. Sociale media kunnen hierbij een waardevolle bron van informatie over iemand zijn. Aangeven bij hetzelfde bedrijf te hebben gewerkt, of dezelfde sport te beoefenen kan vertrouwen wekken. Ook kan gerefereerd worden aan een (zogenaamde) gemeenschappelijke vriend of kennis. Verzoeken die vervolgens gedaan worden, zijn daardoor voor het ‘slachtoffer’ lastiger te weigeren.
Tijdsdruk, het ‘slachtoffer’ geen tijd geven goed over de beslissing na te denken door het schetsen van omstandigheden die een snelle beslissing vereisen. Windows onthoudt vaak de naam van de laatst ingelogde gebruiker (maar niet het wachtwoord). Door achter een (vergrendelde) pc van een gebruiker plaats te nemen kan over het algemeen de account van deze gebruiker worden geblokkeerd door meer dan vijf maal het onjuiste wachtwoord in te voeren. Wanneer een aanvaller bijvoorbeeld op deze wijze een account blokkeert en vervolgens de helpdesk belt en zeg dat hij binnen vijf minuten een belangrijke presentatie moet geven, maar zijn account heeft geblokkeerd, zal deze tijdsdruk er mogelijk toe leiden dat de helpdeskmedewerker (na te hebben vastgesteld dat de account inderdaad zojuist is geblokkeerd) een nieuw tijdelijk wachtwoord instelt en dit via de telefoon doorgeeft, waarna op het systeem kan worden ingelogd.
Het verwijzen naar een hooggeplaatste persoon in de organisatie (autoriteit/gezag). Deze truc werkt vaak bijzonder effectief met het element ‘tijdsdruk’. Door aan te geven dat het ‘slachtoffer’ de werkzaamheden van een hooggeplaatst persoon in de organisatie belemmert en daarom direct op het verzoek dient in te gaan. Een variatie hierop is het zelf door middel van kleding en accessoires ‘afdwingen’ van gezag (zie ook figuur 2). Met een pak en stropdas is het in sommige gevallen veel eenvoudiger om zonder vragen een pand in te komen als met een spijkerbroek en shirtje. Ik ben ooit met een kletsnatte bouwvakkersjas een bank ingelopen met de mededeling dat er in het bovengelegen pand lekkage was. Of ik ‘even achter mocht kijken of het niet door het plafond heen kwam zetten’. De medewerkers waren blij dat ze tijdig gewaarschuwd werden en zonder verdere vragen werd toegang verleend tot de achtergelegen ruimten die alleen voor bankpersoneel toegankelijk waren.

C-2011-2-Paques-02

Figuur 2. Beveiligingsbadges waarmee een social engineer autoriteit kan afdwingen zijn voor enkele euro’s te verkrijgen.

Verzoek om hulp: bijvoorbeeld een verzoek om een bestandje van een USB-stick te printen, die zonder dat het ‘slachtoffer’ het weet, is geïnfecteerd met malware, of bijvoorbeeld het lenen van een elektronische toegangsbadge omdat de eigen badge ‘nog op het bureau ligt’. Een verzoek van een man (de tester) aan een vrouw (het ‘slachtoffer’) of andersom zal in het algemeen eerder worden ingewilligd als bij gelijke sekse.
Gebruik van ‘herkenbare’ zaken voor de organisatie waar het onderzoek wordt uitgevoerd. Personen die een collega denken te herkennen door het dragen van een (al dan niet gekopieerde) toegangsbadge, vergelijkbare stijl van kleding, visitekaartjes, jargon, kennis van werkwijze of namen van informatiesystemen of collega’s (namedropping) zullen minder snel kritische vragen stellen. Wanneer van de naam op de (valse) toegangsbadge ook nog een LinkedIn- of Hyvesprofiel bestaat dat refereert aan het onderzochte bedrijf, zijn de meeste kritische medewerkers ook overtuigd dat ze met een collega te maken hebben.
Een andere methode kan zijn het via de ene medewerker opvragen van gegevens bij een andere medewerker (bijvoorbeeld het laten doorzetten van gegevens naar een bestaande interne afdeling die vervolgens benaderd wordt om de ‘verkeerd gestuurde e-mail’ door te zetten). Door gebruik te maken van deze interne referenties wordt de geloofwaardigheid vergroot. Een ander voorbeeld is het opnemen van de wachtmuziek, die bedrijven gebruiken als bellers in de wacht worden gezet. Wanneer je vervolgens belt met een medewerker zeg je na een paar minuten: ‘Wacht even, ik krijg een andere lijn binnen’, en zet het ‘slachtoffer’ in de wacht. Vervolgens speel je het wachtmuziekje af dat je eerder hebt opgenomen, waardoor het ‘slachtoffer’ onbewust denkt: ‘Hé, dat is ons melodietje, hij werkt dus bij ons’.
Aangeven dat ‘alle collega’s’ van het ‘slachtoffer’ op dezelfde wijze hebben gehandeld, dus dat het verzoek ‘héél normaal’ is. Mensen zijn geneigd iets als juist te beschouwen wanneer anderen dezelfde keuze hebben gemaakt. Een variatie hierop is het opbouwen van (informatie)verzoeken. Wanneer iemand al op een aantal verzoeken is ingegaan (bijvoorbeeld het opzoeken van compleet niet relevante informatie) zal het moeilijker zijn vervolgens een verzoek om vertrouwelijke informatie af te slaan.
Noodzaak om iets ‘terug te moeten doen/compenseren‘ creëren. Door mensen iets te geven kan de gevoelsmatige verplichting gecreëerd worden jou iets verschuldigd te zijn. Hierdoor wordt het makkelijker iemand aan een verzoek te laten voldoen als zijnde normaal. Wanneer je iets voor iemand hebt gedaan (ook al heeft degene hier helemaal niet om gevraagd) wordt het voor deze persoon veel lastiger om een verzoek tot een wederdaad te weigeren.
De indruk geven dat het eigenlijke verzoek al een concessie is. Wanneer het genoeg is om ergens vijf minuten binnen te zijn, kan het zinvol zijn in te zetten op een rondleiding door het pand, maar als dit niet kan dan erop aan te dringen dat er in ieder geval even vijf minuten rondgekeken mag worden.
Het aanbieden van iets wat leidt tot een persoonlijk voordeel. Bijvoorbeeld een phishing-e-mail met de code voor het bestellen van het persoonlijk kerstpakket.
Het veroorzaken van ‘onvoorziene situaties’, waardoor medewerkers (en in het bijzonder beveiligingsmedewerkers) niet meer in staat zijn hun gebruikelijke routine te volgen. Zo zijn we wel eens verkleed als Sinterklaas en Zwarte Piet een zwaarbeveiligd datacentrum binnengedrongen (figuur 3). Het datacentrum lag op een afgezonderde locatie en was omgeven door metershoge hekken met prikkeldraad, tientallen camera’s en een aarden wal die het zicht op het gebouw ontnam. Een week van tevoren hadden we de beveiliging al aan de telefoon gehad en ons voorgedaan als HR-medewerkers die belden in verband met de aankomende Sinterklaasactiviteiten op de verschillende locaties. De beveiliging had dus al ‘iets’ van de activiteiten gehoord, maar werd toch overrompeld door de situatie. Om op het terrein te komen moest eerst een soort ‘checkpoint Charlie’ worden gepasseerd waar een beveiligingsmedewerker achter kogelvastglas met de beveiliging binnen overlegde over de te nemen stappen. Min of meer tot onze eigen verbazing werden we doorgelaten het terrein op, terwijl de deur achter ons weer vergrendeld werd. Bij het datacentrum zelf aangekomen liepen we ook weer direct tegen een glazen beveiligingsruimte aan waar zich een vijftal beveiligingsmedewerkers bevond. Eén blik in onze zware zak met kilo’s pepernoten was voldoende geweest om de opnameapparatuur van de spionagecamera (figuur 4) te ontdekken en ons te ontmaskeren. ‘Hallo! Hier zijn we dan!!’, riepen we, en vulden het bakje waar normaliter de paspoorten onder het glas worden doorgeschoven met pepernoten. Nadat we één van de beveiligers nog hadden omgekocht met een chocoladeletter hebben we een rondje door het pand gemaakt en zijn we zonder problemen weer vertrokken.
Gebruik van een afleidingsmanoeuvre, bijvoorbeeld het meenemen van die leuke vrouwelijke collega met hoge hakken en een kort rokje.

C-2011-2-Paques-03

Figuur 3. De ‘Sinterklaas en Zwarte Piet’ die het datacenter wisten binnen te dringen.

C-2011-2-Paques-04

Figuur 4. Een ‘knoopcamera’ waarmee ongemerkt bijvoorbeeld toetsaanslagen gefilmd kunnen worden.

Afhankelijk van de specifieke situatie bij de klant worden aanvalsscenario’s uitgewerkt waarin veelal één of meer van bovenstaande technieken worden toegepast. In praktijkvoorbeeld 2 wordt bijvoorbeeld een band opgebouwd met het ‘slachtoffer’, herkenning gecreëerd door te refereren aan interne afdelingen, gerefereerd aan een persoonlijk voordeel (het niet verliezen van data) en een compromis gesloten (laatste alinea). Doordat er sprake is geweest van eerdere ‘hulp’ wordt tevens de noodzaak tot ‘compensatie’ gecreëerd.

Praktijkvoorbeeld 2

Bij een test waarbij het doel was systeemtoegang te verkrijgen heb ik een medewerkster gebeld met de melding dat er waarschijnlijk een probleem was met haar systeem en dat dit een enorme hoeveelheid netwerkverkeer op het netwerk veroorzaakte. Ik gaf aan dat het systeem hier uiteindelijk door kon vastlopen en in het ergste geval de aanwezige data niet meer benaderbaar zouden zijn. Op mijn vraag of de laptop niet erg traag was de laatste tijd kreeg ik uiteraard een bevestigend antwoord. Na wat willekeurig getik op mijn toetsenbord zei ik dat ik het probleem had gevonden, benadrukte dat het erg lastig was dit op te lossen, maar dat ik ermee bezig ging. Ik hing op en belde na een half uurtje opnieuw om te vertellen dat het probleem was opgelost. Nadat ze mij nadrukkelijk had bedankt hing ik op.

Twee dagen later belde ik opnieuw en zei dat het probleem helaas toch niet opgelost bleek te zijn en ook op de laptop zelf aanpassingen moesten worden doorgevoerd. Ik vroeg of ze de laptop even bij local IT kon langsbrengen (die ik al in een eerder gesprek had gebeld om vast te stellen hoe de procedure werkte en om te controleren dat deze daadwerkelijk een lokaal servicepunt had) om daarmee de indruk te wekken dat ik daadwerkelijk een interne medewerker was. De medewerkster was echter erg druk en dit kwam erg slecht uit. Bij wijze van uitzondering wilde ik dan ook wel op afstand kijken of ik het probleem kon oplossen, zei ik. Omdat we, zo liet ik weten, vanuit veiligheidsoogpunt nooit aan gebruikers vragen hun wachtwoord over de telefoon af te geven, vroeg ik haar om het wachtwoord tijdelijk te veranderen in ‘welkom123’, zodat ik dan op afstand het probleem kon oplossen. Twee minuten later kon ik op de laptop inloggen en had ik toegang tot de (vertrouwelijke) data die ik nodig had.

Methoden

Hieronder enkele veelgebruikte methoden die ingezet worden tijdens een social-engineering aanval. Bij deze methoden wordt deels gesteund op de eerder beschreven psychologische ‘trucs’. De combinatie van methoden vormt samen het aanvalsscenario.

C-2011-2-Paques-05

Figuur 5. De samenhang tussen methoden, trucs en een aanvalsscenario.

Phishing: vorm van aanval waarbij gebruik wordt gemaakt van e-mails of internetpagina’s die van een legitieme partij lijken te zijn, bijvoorbeeld van de eigen werkgever, maar in werkelijkheid worden beheerd door de aanvaller. Deze mails of pagina’s hebben veelal tot doel gegevens van medewerkers (bijvoorbeeld wachtwoorden) te verzamelen.
Dumpster diving: het doorzoeken van prullenbakken, bakken bij kopieermachines of buiten geplaatste containers van een organisatie op zoek naar waardevolle informatie. ‘Waardevolle informatie’ kan in dit geval bijvoorbeeld ook briefpapier of visitekaartjes zijn omdat deze weer kunnen worden gebruikt in een volgende aanval.
Pretexting: het onder valse voorwendselen (de pretext) verkrijgen van informatie. Bijvoorbeeld het bellen van een medewerker en je voordoen als een interne collega.
Tailgating: het ‘meeliften’ met een medewerker om door een beveiligd toegangspoortje te komen om zo fysieke toegang tot een beveiligde locatie te krijgen.
Reverse Social Engineering: een methode waarbij het ‘slachtoffer’ zodanig gemanipuleerd wordt dat deze de social engineer om hulp zal vragen. De social engineer creëert voor het ‘slachtoffer’ een probleem en zal zich vervolgens kenbaar maken als ‘expert’ die het probleem kan oplossen. Vervolgens zal de social engineer het verzoek van het ‘slachtoffer’ afwachten. Omdat het initiatief bij het ‘slachtoffer’ ligt is er sneller een vertrouwensband.
Shoulder Surfing: meekijken bij het intoetsen van een wachtwoord of pincode. Hier hoeft niet daadwerkelijk te worden meegekeken. Bij verschillende tests wordt gebruikgemaakt van miniatuur-spionagecamera’s, bijvoorbeeld een knoopcamera (figuur 4), waarbij je één van de knopen in je jasje vervangt door een knoop met camera. Wanneer hiermee het intoetsen van een wachtwoord wordt opgenomen, kan dit later vanuit de opnamen worden teruggekeken.
Het plaatsen van afluisterapparatuur (bugs), draadloos access point of keylogger. Wanneer toegang is verkregen tot een pand kan vaak eenvoudig afluisterapparatuur worden geplaatst. Moderne afluisterapparatuur is voor een beperkt budget te verkrijgen en kan bijvoorbeeld een van tevoren ingesteld GSM-nummer bellen zodat via de telefoon live kan worden meegeluisterd (figuur 6). Alternatief wordt een keylogger geïnstalleerd (figuur 7). Deze kan in enkele seconden tussen het toetsenbord en de systeemkast van een gebruiker worden ingeklikt en slaat vervolgens alle toetsaanslagen op. Huidige versies van keyloggers kunnen deze vervolgens automatisch via een draadloos netwerk via mail doorsturen naar de aanvaller. Het verborgen intern plaatsen van een access point (bijvoorbeeld door deze achter een radiator te verstoppen) kan ook zinvol zijn. Wanneer deze op het netwerk is aangesloten kan de aanvaller vervolgens weer het pand verlaten en van buitenaf (bijvoorbeeld vanuit de auto) het interne netwerk aanvallen door een verbinding te maken met het zojuist geïnstalleerde access point met een kleine kans te worden opgespoord en opgepakt.

C-2011-2-Paques-06

Figuur 6. ‘Audiobug’ waarmee via GSM gesprekken kunnen worden afgeluisterd.

C-2011-2-Paques-07

Figuur 7. Keylogger die alle toetsaanslagen verzamelt.

Malware: kwaadaardige software die bijvoorbeeld wachtwoorden verzamelt en doorstuurt naar een e-mailadres van de aanvaller. Malware kan op het systeem geplaatst worden door middel van bijvoorbeeld een geïnfecteerde pdf-file ([Paqu01]). De pdf-file kan worden verspreid door bijvoorbeeld het achterlaten van een USB-stick met daarop bestanden als ‘loonlijst 2011’ of ‘fraudeonderzoeken 2011’. Ideale plaatsen om dergelijke sticks achter te laten is bij de toiletten of het koffieapparaat. Wanneer het ‘slachtoffer’ de pdf-file opent wordt daarmee ongemerkt tevens de malware opgestart.

In praktijkvoorbeeld 3 wordt een aantal van de hierboven genoemde methoden toegepast. Dit voorbeeld laat onder andere zien hoe informatie die wordt verkregen vanuit de ene aanval, kan worden gebruikt in een volgende aanval om daarmee meer informatie te verkrijgen.

Praktijkvoorbeeld 3

Het is even over achten als ik mijn auto op een kleine honderd meter afstand van het pand van één van onze klanten neerzet. Ik heb eerder vastgesteld dat de meeste medewerkers met de auto komen en deze achter het hoofdkantoor neerzetten op de besloten parkeerplaats, dus het lijkt me het beste om dit patroon te volgen omdat het lopend de parkeerplaats opgaan al mogelijk de aandacht trekt. In mijn spiegel houd ik in de gaten of er medewerkers aan komen rijden. Na een minuut of tien verschijnt er een grijze personenauto. Zodra de wagen mij passeert, voeg ik in en volg op korte afstand. Helaas rijdt de auto het pand van het doelwit van vandaag voorbij en word ik gedwongen via een rondje weer terug te gaan naar mijn beginpositie. De tweede keer heb ik meer geluk en kan ik, nadat de medewerker met zijn personeelspas de slagboom heeft geopend, op korte afstand volgen tot op het besloten parkeerterrein achter het pand. Ik wacht even tot de medewerker uit de auto voor mij via de personeelsingang aan de achterzijde het pand is ingegaan en loop naar de rookplek vlak voor de ingang. Ik pak het nieuwe pakje sigaretten uit mijn zak, steek er één aan. Gelukkig zijn er geen camera’s aan deze zijde van het pand, dus kan ik hier rustig even blijven hangen tot er een nietsvermoedende medewerker aanhaakt om te komen roken met deze niet-roker, die voor de gelegenheid maar even met een sigaret staat te zwaaien. Op gegeven moment verschijnt er een dame die zich bij mij voegt om ook te roken, we maken een praatje en lopen gezamenlijk – door met haar personeelspas de deur te openen – het pand in. Binnen! Ik besluit gelijk maar in volgmodus het trappenhuis in te lopen, want deze klant heeft zo te zien ook paslezers bij de deuren naar de verschillende verdiepingen aangebracht.

Ik volg haar naar de vierde etage en betreed, opnieuw doordat zij netjes de deur voor ons opent, de verdieping. Gelukkig staat er een koffieapparaat dus kan ik daar de verdieping observeren zonder mezelf klem te lopen in één of ander doodlopend deel van het pand. Even verderop blijken wat vergaderruimteachtige werkplekken te zitten. Ik neem mijn koffie mee, trek in de vergaderzaal de kabel uit de VoIP-telefoon en prik deze in mijn laptop. Terwijl mijn laptop opstart, werp ik een blik op de stapel papier die ik zojuist in het langslopen uit de verzamelbak naast de printer heb meegegrist. Onder andere e-mails, met een hoop mailadressen van medewerkers in de ‘To’- en ‘CC’-velden. Mooi zo! Dit worden mijn ‘slachtoffers’ in de volgende aanval.

Mijn laptop is inmiddels opgestart en ik start een poortscan op poort 80 op de nabijgelegen IP-adressen op zoek naar wat interne webpagina’s. Tevens probeer ik via mijn webbrowser een aantal voor de hand liggende url’s. ‘intranet.klantnaam.nl’,’ intraweb.klantnaam.nl’, ‘search.klantnaam.nl’, ‘telefoongids.klantnaam.nl’. Na niet al te lang zoeken heb ik een interne webpagina gevonden. Ik kopieer de pagina en pas wat teksten aan en na een kwartiertje heb ik een ‘medewerker van de maand’-verkiezingspagina in elkaar gezet die er precies zo uitziet als de pagina’s van het bedrijf zelf inclusief bijbehorende logo’s en kleuren. Vervolgens start ik de webserver op mijn eigen laptop zodat de zojuist gemaakte pagina vanaf het interne netwerk kan worden benaderd.

Door een tweede beperkte poortscan weet ik een interne mailserver te identificeren waarop mail relaying aanstaat (waardoor anoniem e-mail verstuurd kan worden). Ik ben inmiddels zeker twintig minuten in het pand en nog niemand heeft me tot nu toe vragen gesteld over wat ik hier doe. Nu richt ik me weer op de ‘slachtoffers’. Via de mailserver stuur ik allereerst een mail met een vals extern e-mailadres dat ik vanuit mijn spamfolder heb gekopieerd naar een deel van de adressen in de uitgeprinte e-mails. Ik hoop op deze test-e-mails een out-of-office bericht terug te krijgen van één van de medewerkers. Wanneer ik deze inderdaad retour krijg, kopieer ik de ondertekening en pas naam en functie aan naar een fictieve naam. Ik heb nu een webpagina én een e-mailbericht die er precies zo uitzien alsof ze van de eigen organisatie zijn. Vervolgens zet ik in de e-mail een Reminder van de uitnodiging voor de ‘medewerker van de maand’-verkiezing. De mail geeft aan dat een willekeurig gekozen selectie van medewerkers één van hun collega’s kan nomineren voor deze prijs. Dit kan via een interne webpagina waarvan de link onderaan de e-mail is opgenomen. Uiteraard moet wel worden ingelogd om te voorkomen dat mensen dubbele stemmen uitbrengen. De reminder geeft aan dat degene die de eerste mail hebben gemist nog tot 12:00 uur dezelfde dag de kans hebben om hun stem uit te brengen. Ik switch naar een tweede venster waar ingetoetste wachtwoorden zullen verschijnen en wacht rustig af tot de eerste enthousiastelingen hun wachtwoord inkloppen. Dit duurt op de kop af twee minuten na het versturen van de e-mail.

Met het inloggen op de site hebben de medewerkers automatisch naast hun wachtwoord ook hun gebruikersnaam en IP-adres achtergelaten. Dit is voor mij alle informatie die ik nodig heb en ik start Metasploit (een hackers toolkit) en log hiermee op afstand in op de pc van de eerste enquêtedeelnemer. Inmiddels heb ik de gebruiker ook teruggevonden in de interne online telefoongids. Helaas blijkt de eerste medewerker op de financiële afdeling te werken. In deze fase ben ik meer op zoek naar een IT-beheerder omdat deze vaak hoge gebruikersrechten hebben en daarmee toegang tot een groot aantal of alle systemen. Ik besluit een dump te maken van de lokale wachtwoord-hashes. Met de hash van de lokale administrator account probeer ik vervolgens te authenticeren tegen het systeem van een willekeurige andere gebruiker op het netwerk. Deze ‘truc’ heeft al bij verschillende klanten gewerkt en blijkt ook nu succesvol. Inmiddels ben ik zo’n drie kwartier binnen zonder dat dit iemand is opgevallen en heb ik reeds twee systemen volledig overgenomen. Helaas werkt de hash niet op de domain controller, dus besluit ik net zo lang op systemen in te loggen tot ik een systeem tref waar een gebruiker (of proces) aanwezig is met hoge rechten (bijvoorbeeld de IT-beheerder). Na twintig minuten vind ik een systeem waarop een IT-beheerder is ingelogd. De tool Metasploit, die overigens gratis te downloaden is, heeft een ingebouwde functie om de identiteit, en daarmee alle rechten van een gebruiker over te nemen. Nadat ik de identiteit van IT-beheerder heb overgenomen, heb ik domain administrator rechten en volledige toegang tot alle Windows-systemen en daarop aanwezige data op het netwerk, inclusief alle servers met financiële administratie en de mailboxen van de directie. Ik maak wat screenshots en vind dat het tijd is voor een tweede kop koffie.

Uit praktijkvoorbeeld 3 blijkt dat het niet altijd van belang is hoeveel medewerkers daadwerkelijk in de trucs van een social engineer trappen. In deze specifieke situatie was het voor een buitenstaander al voldoende om slechts twee medewerkers te misleiden om vervolgens de volledige IT-omgeving te kunnen overnemen.

Maatregelen

Bewustzijn

Het sleutelwoord tegen social-engineering aanvallen is bewustzijn, of specifieker gezegd, kennis van de mogelijke doelwitten en van de technieken van een aanvaller, maar ook kennis van de eigen zwakheden. Bij één van mijn opdrachten had de klant op alle verdiepingen naast de gebruikelijke papierbakken bij de printers grote afgesloten bakken voor vertrouwelijk papier geplaatst. Een greep in de bak voor gewoon afvalpapier leverde echter een grote stapel met vertrouwelijke documenten op (rapporten van security-incidenten, HR-informatie, wachtwoorden, enz.) Waarom? Vermoedelijk was het te veel moeite geweest om de stapels papier door de kleine sleuf van de bak voor vertrouwelijk papier te proppen en was in één keer weggooien makkelijker.

Wanneer klanten in een presentatie of training horen hoe een truc werkt, zegt men over het algemeen iets als ‘dan moet je wel echt naïef zijn om daar in te trappen, dat zou bij mij niet lukken’. De praktijk is echter vaak anders. Om echt bewustzijn te creëren is het daarom naast het verschaffen van informatie zinvol om een test/oefening uit te voeren. Hierdoor zien mensen vaak in dat ze helemaal niet zo bestand zijn tegen een dergelijke aanval als ze vaak zelf denken en wordt daadwerkelijk bewustzijn gecreëerd. Naast het creëren van bewustzijn is een test een prima middel om de risico’s in kaart te brengen.

Richtlijnen

Naast bewustzijn is het opstellen van richtlijnen en het controleren van de naleving daarvan essentieel. Hierbij kan bijvoorbeeld gedacht worden aan ‘tien regels voor informatiebeveiliging’. Deze zouden er bijvoorbeeld als volgt uit kunnen zien:

Maak je wachtwoorden in geen enkel geval bekend aan anderen (ook niet aan IT-medewerkers).
Deel geen interne informatie met buitenstaanders.
Houd je aan de clean desk en whiteboard policy.
Vergrendel je computer als je je werkplek verlaat.
Laat geen informatie bij de printer achter.
Maak gebruik van beveiligde afvalbakken voor vertrouwelijke gegevens.
Verifieer de identiteit van de gesprekspartner wanneer gevraagd wordt om vertrouwelijke gegevens. (In geval van een telefonisch verzoek kan dit bijvoorbeeld door de beller terug te bellen op een vast nummer.)
Sla vertrouwelijke informatie nooit lokaal of op een privé-pc op.
Alarmeer bij verdachte zaken direct de security officer.
Draag de toegangsbadge zichtbaar en wijs collega’s op het dragen van deze badge. Onbekenden zonder badge dienen naar de uitgang van het pand te worden geëscorteerd en daar worden overgedragen aan de receptie/beveiliging.

Om een effectieve naleving van dergelijke regels te bewerkstelligen dient te worden gecontroleerd of medewerkers deze daadwerkelijk naleven. Bevindingen hieruit (zowel positief als negatief) dienen naar de betreffende medewerkers te worden teruggekoppeld.

Conclusie

Wellicht denkt u na het lezen van dit artikel dat de genoemde voorbeelden onmogelijk gebeurd kunnen zijn en dat dergelijke voorvallen in de praktijk niet zullen slagen. De werkelijkheid is echter dat deze en vergelijkbare aanvallen elke dag plaatsvinden en dat ondanks allerlei beveiligingsmaatregelen als beveiligingspersoneel, hekken met prikkeldraad, toegangspasjes, camerabewaking, alarminstallaties en dergelijke social engineers weten door te dringen tot het hart van de organisatie. Het uitvoeren van een social-engineering test kan een goede methode zijn om de risico’s in een organisatie in kaart te brengen en het bewustzijn van medewerkers te verhogen.

Literatuur

[Hadg01] Christopher Hadgany, Social engineering – the art of human hacking, 2010.

[Mitn01] Kevin D. Mitnick en William L. Simon, The Art of Deception, 2002.

[Paqu01] Matthieu Paques, Hacken met PDF-files, https://www.compact.nl/articles/hacken-met-pdf-files/.

[security.nl] : artikelen inzake social-engineering aanvallen http://www.security.nl/tag/social%20engineering.

De meldplicht datalekken

Een securitybedrijf wordt gehackt en beveiligde identiteitstokens lekken naar buiten, de gegevens van klanten van een fastfoodketen liggen voor het oprapen en de tapgegevens van het KLPD zijn ook al niet veilig … Datalekken komen helaas vaak voor. En ook steeds vaker komt dit publiekelijk naar buiten. Nog even en dan is het zelfs wettelijk verplicht dergelijke datalekken openbaar te maken; op 29 april 2011 maakten Teeven (ministerie V&J) en Donner (ministerie BZK) bekend dat een brede meldplicht voor alle aanbieders van informatiediensten opgenomen zal worden in de Wet bescherming persoonsgegevens. Op korte termijn zal een zogenaamde ‘smalle meldplicht’ gaan gelden voor alleen telecommunicatiebedrijven en internet-serviceproviders op grond van een wijziging van de Telecommunicatiewet.

Inleiding

Datalekken zijn helaas bijna aan de orde van de dag. En het overkomt de besten onder ons. Niet lang geleden kampte zelfs een securitybedrijf met het uitlekken van informatie over beveiligde IDtokens. Soms had een lek makkelijk voorkomen kunnen worden, een andere keer is er sprake van domme pech of een geavanceerde aanval van buitenaf. Hoe het ook zij, het uitlekken van persoonlijke data van werknemers, klanten of anderszins is buitengewoon vervelend en ook problematisch in verband met allerlei juridische garanties die de ‘eigenaars’ van deze data verstrekt worden. 2011 wordt het jaar dat de (smalle) meldplicht datalekken in werking zal treden. Als alles volgens planning verloopt, moet dit voorjaar al de implementatie daarvan in de Telecommunicatiewet (Tw) gereed zijn. Vooralsnog geldt de meldplicht alleen voor telecommunicatiebedrijven (telco’s) en Internet Service Providers (ISP’s). Een bredere meldplicht die zal gelden voor alle aanbieders van informatiediensten (denk bijvoorbeeld aan banken, de Belastingdienst en verzekeringsmaatschappijen), is op 29 april aangekondigd door Teeven en Donner en zal een plaats krijgen in de Wet bescherming persoonsgegevens. Voorstanders van de meldplicht, zoals onder meer burgerrechtenorganisatie Bits of Freedom en de Consumentenbond, staan hier uitermate positief tegenover. Dit vanuit de wens tot meer transparantie en openheid daar waar het misgaat met de persoonlijke gegevens van burgers en klanten. Het bedrijfsleven weifelt. De gevolgen van een dergelijke meldplicht kunnen groot zijn, reputatieschade en praktische uitvoering lijken de meest voor de hand liggende factoren bij terughoudendheid. Dit artikel gaat nader in op de meldplicht datalekken: wat is het en hoe zal die gaan werken? En hoe zit dat met een meldplicht voor alle organisaties die te maken (kunnen) krijgen met datalekken? Daarnaast worden enkele voor- en tegenargumenten op een rijtje gezet.

Data Loss Barometer

Hoewel uit onderzoek van KPMG blijkt dat er sprake is van een daling in de hoeveelheid incidenten waarbij persoonlijke data gelekt worden, is er desalniettemin nog steeds sprake van een enorme hoeveelheid gevallen waarbij data ‘verloren’ gaan ([KPMG10]). Meer dan 15 miljoen mensen worden hierdoor geraakt. Vooral binnen de financiële sector is het verlies van data ongemeen groot, zeker indien dit afgewogen wordt tegen de andere in de Data Loss Barometer onderzochte sectoren. Van de in totaal verloren ‘records’ is 33% afkomstig uit die financiële sector, maar ook retail (31%) en de informatiediensten (22%) scoren hoog. In 21% van de gevallen wordt het lek veroorzaakt door zogenaamde ‘malicious insiders’ (kwaadwillenden van binnen in de organisatie), 15% wordt veroorzaakt door de diefstal van pc’s en 12% vindt zijn oorsprong in hacks.

C-2011-2-Marbus-01 C-2011-2-Marbus-02

Figuur 1. Dataverlies naar sector (boven) en naar oorzaak (bron: [KPMG10]).

De wordingsgeschiedenis van de meldplicht

Al sinds 2005 wordt er in politiek Nederland gestreden voor het invoeren van een wettelijke regeling rondom het verplicht melden van datalekken. Een motie van SP en PvdA uit 2005 met betrekking tot het invoeren van een meldplicht haalde het toentertijd niet. Toenmalig minister Donner oordeelde dat persoonsgegevens al afdoende beschermd werden onder het regime van de Wet bescherming persoonsgegevens. Eventuele door de markt zelf op te stellen regels zouden verdere bescherming moeten afdwingen. Indertijd is wel toegezegd dat onderzoek zou worden gedaan naar de vraag of een dergelijke meldplicht effect sorteert. Dit door te kijken naar de resultaten van de landen waar al wel een wettelijke plicht vastgelegd is. Het duurt daarna echter weer enkele jaren voor de discussie over de meldplicht opnieuw oplaait. In 2009 komen het Europees Parlement en de Raad met een aantal wijzigingen voor de zogenaamde ePrivacy-richtlijn, waarin onder meer een meldplicht is opgenomen voor de aanbieders van openbare telecommunicatiediensten (lees: telco’s en internet-serviceproviders). Daarmee komt een smalle meldplicht wettelijk vast te liggen, alle EU-lidstaten verplichten zich dit in de nationale wetgeving op te nemen. Eerder zei Hirsch Ballin in antwoord op Kamervragen al dat de wijze waarop dit alles wordt vormgegeven, nog nader bepaald zal gaan worden. De zogenaamde ‘smalle’ meldplicht zou evenwel in mei 2011 geïmplementeerd dienen te zijn in de Nederlandse wet.[Antwoord op Kamervragen van Gesthuizen, Aanhangsel van de handelingen 165, vergaderjaar 2010-2011.] De Europese privacywaakhond, de artikel 29 werkgroep, had echter al in het advies op het voorstel tot wijziging van de ePrivacy-richtlijn aangegeven dat ‘An extension of personal data breach notifications to Information Society Services is necessary given the ever increasing role these services play in the daily lives of European citizens…’.[Opinion 1/2009 on the proposals amending Directive 2002/58/EC on privacy and electronic communications (e-Privacy Directive), p. 8.] Daarmee zouden alle dienstaanbieders van de informatiemaatschappij onder de plicht gaan vallen. Het advies werd niet overgenomen, maar is ook niet ongemerkt voorbijgegaan. Over de brede meldplicht volgt later in dit artikel meer.

Wat is dan die meldplicht datalekken?

De meldplicht komt voort uit wijzigingen van de Europese privacy- en telecommunicatiewetgeving.[RICHTLIJN 2009/136/EG VAN HET EUROPEES PARLEMENT EN DE RAAD van 25 november 2009 tot wijziging van Richtlijn 2002/22/EG inzake de universele dienst en gebruikersrechten met betrekking tot elektronische communicatienetwerken en -diensten, Richtlijn 2002/58/EG betreffende de verwerking van persoonsgegevens en de bescherming van de persoonlijke levenssfeer in de sector elektronische communicatie en Verordening (EG) nr. 2006/2004 betreffende samenwerking tussen de nationale instanties die verantwoordelijk zijn voor handhaving van de wetgeving inzake consumentenbescherming.] Deze ‘smalle’ meldplicht wordt opgenomen in de Telecommunicatiewet. In het voorstel van wet staat onder meer:

Artikel 11.3b

De aanbieder van een openbare elektronische communicatiedienst stelt het college onverwijld in kennis van een inbreuk in verband met persoonsgegevens.
De aanbieder bedoeld in het eerste lid stelt degene wiens persoonsgegevens het betreft onverwijld in kennis van een inbreuk in verband met persoonsgegevens indien de inbreuk naar verwachting nadelige gevolgen heeft of kan hebben voor diens persoonlijke levenssfeer.

Als een inbreuk heeft plaatsgevonden waarbij persoonsgegevens in het geding zijn, dan moet de nationale bevoegde instantie in kennis gesteld worden van dit datalek – voor Nederland is dat het College bescherming persoonsgegevens. Dit moet zonder onnodige vertraging (lees eigenlijk ‘vrijwel direct’) gebeuren. Daarbovenop vereist de nieuwe regelgeving dat ook de personen om wier gegevens het gaat een bericht ontvangen, echter, dan moet er wel sprake zijn van waarschijnlijk nadelige gevolgen voor de persoonlijke levenssfeer van het individu. Er moeten dus mogelijk nadelige gevolgen voor de privacy van personen in het geding zijn. Zijn de gegevens bijvoorbeeld dermate versleuteld dat leesbaarheid daarvan niet erg aannemelijk is, dan mag die aanbieder ervan afzien om zijn klanten van het lek op de hoogte te brengen.

De nationaal bevoegde instantie (het Cbp) kan de aanbieders zelfs dwingen om het datalek in de openbaarheid te brengen als ze van oordeel is dat de inbreuk ongunstige gevolgen kan hebben. Als aanbieder moet je in het geval van de melding wel een aantal zaken op orde hebben. Zo moet gemeld worden:

de aard van de inbreuk op de persoonsgegevens;
de contactpunten voor meer informatie;
aanbevolen maatregelen om de gevolgen van de inbreuk te verlichten (voor degene wiens gegevens betrokken zijn in het lek);
een omschrijving van de gevolgen; en
een omschrijving van de getroffen of voorgestelde maatregelen om de inbreuk daadwerkelijk aan te pakken.

De regeling kan zelfs zover strekken dat de nationaal bevoegde instantie specifieke aanwijzingen mag geven over hoe deze publieke kennisgeving gedaan moet worden; daarbij moet gedacht worden aan de manier waarop (online, via de eigen website, in de landelijke media, etc.) en het toepasselijke formaat daarvan. Overigens, als de aanbieder verzaakt het datalek te melden aan de bevoegde nationale instantie, kunnen sancties opgelegd worden. Wat betreft het College bescherming persoonsgegevens kan dan gedacht worden aan een last onder dwangsom of een bestuurlijke boete.[Artt. 65-75 Wbp.] En daarbovenop kan dan dus nog eens die openbaarmaking van het lek komen.

Niet iedereen wacht op het verschijnen van de wetgeving. Bits of Freedom heeft al enige tijd een eigen Zwartboek datalekken, waarop verschillende forse lekken uitgebreid uit de doeken worden gedaan.[Zie: www.bof.nl/category/zwartboek-datalekken/.] Dat het echt niet alleen maar gaat om uit burgerrechtelijke hoek gedane meldingen van datalekken, bewijst Gawker Media, dat in het openbaar te kennen gaf dat op de servers van het bedrijf een inbreuk had plaatsgevonden.[Zie: http://lifehacker.com/5712785/faq-compromised-commenting-accounts-on-gawker-media.] Bedrijven nemen dus ook zelf de verantwoordelijkheid op zich om lekken kenbaar te maken. Sterker nog, Gawker Media hield het niet alleen maar bij het melden dat er iets misgegaan was. Zo legde ze een uitgebreide FAQ aan waar gebruikers van hun websites onder meer kunnen lezen wat te doen als ze de account van Gawker-websites gelinkt hebben aan Facebook of Twitter, hoe de account van Gawker gedeletet kan worden en waarin ook uitgebreid aandacht is voor datgene wat het bedrijf zelf doet om het lek te dichten en de gevolgen zoveel mogelijk te beperken.

C-2011-2-Marbus-03

Figuur 2. Pagina van de website Zwartboek datalekken.

Een brede meldplicht datalekken

De meldplicht die dit jaar in werking moet gaan treden, treft slechts een gedeelte van de organisaties die te kampen (kunnen) hebben met het weglekken van data. Zoals eerder al aangegeven, is de roep om een bredere meldplicht al langere tijd sterker aan het worden. Zo geeft Eurocommissaris Kroes in de digitale agenda aan dat er op EU-niveau in ieder geval nagedacht wordt over een bredere meldplicht, alhoewel nog met een lichte slag om de arm: ‘In het kader van de recent opgezette herziening van het algemene gegevensbeschermingskader zal de plicht om dergelijke inbreuken tegen de gegevensbeveiliging te melden, eventueel worden uitgebreid’.[Een digitale agenda voor Europa, COM/2010/0245 f/2.] En ook in Nederland zelf lijkt het erop dat een brede meldplicht, voor zowel de overheid als de private sector, inmiddels serieus dichtbij komt, daarmee dus wellicht zelfs vooruitlopend op regelgeving van Europese kant. In de evaluatie van de Wet bescherming persoonsgegevens in maart 2010 merkte Hirsch Ballin echter al op: ‘De gedachte voor het invoeren van een meldplicht bij datalekken ondersteunen wij. Deze meldplicht zou een goede bijdrage zijn aan het bevorderen van de transparantie die een van de uitgangspunten moet blijven bij de bescherming van persoonsgegevens. Je moet kunnen weten wie jou registreert en op welke manier. De implementatie van het EU-brede traject (de smalle meldplicht – RM) verwachten wij dit kalenderjaar af te ronden’.[AO, TK 31051, 2009-2010, p. 20.] Hoe precies invulling gegeven kan worden aan die meer brede meldplicht wordt uit de evaluatie helaas nog niet duidelijk. Er is dus wel degelijk al langere tijd veel aandacht voor de realisering van de brede meldplicht en de discussie beperkt zich (gelukkig) niet alleen binnen de grenzen van het ‘privacydebat’. Ook in de begin 2011 gepresenteerde Nationale Cyber Security Strategie (NCSS) wordt binnen de paragraaf rondom het vergroten van de weerbaarheid van de vitale infrastructuur gerefereerd aan een brede meldplicht datalekken.[De Nationale Cyber Security Strategie, Slagkracht door samenwerking, 22 februari 2011.] De Memorie van Toelichting bij het wetsvoorstel rondom wijziging van de Telecommunicatiewet gaat expliciet in op de brede meldplicht. Daarin wordt nog eens benadrukt dat de minister van Justitie de Tweede Kamer de toezegging heeft gedaan dat er een concreet voorstel zal komen voor een brede meldplicht. Die brede meldplicht zal dan opgenomen gaan worden in de Wet bescherming persoonsgegevens. En ook wat dat aangaat, zal het College bescherming persoonsgegevens de instantie zijn die toezicht moet leveren op de naleving van de meldplicht.[Memorie van Toelichting wetsvoorstel wijziging Telecommunicatiewet, paragraaf 1.8 ‘Bescherming van persoonsgegevens en de persoonlijke levenssfeer’, 15 april 2010.] Op 29 april maakten staatssecretaris Teeven en minister Donner officieel bekend dat
de Wet bescherming persoonsgegevens aangepast zal worden en dat daarin een brede meldplicht opgenomen wordt voor alle aanbieders van informatiediensten.[Zie hiervoor onder meer het persbericht van 29 april 2011 op www.rijksoverheid.nl.] Het kabinet heeft aangegeven dat het een wetsvoorstel daartoe dit jaar nog ter consultatie zal willen aanbieden.

Wat is er nu voor en wat is er nu tegen?

Overduidelijk pluspunt: meer privacybescherming voor individuen. Althans, meer wetenschap over het feit dat er een inbreuk heeft plaatsgevonden. Het kwaad is al wel geschied, maar dat is praktisch inherent aan een inbreuk op de privacy en wordt daarom door privacyspecialisten al geruime tijd één van de ‘privacyparadoxen’ genoemd.[Een andere vaak gehoorde paradox is dat personen vaak zeggen veel waarde te hechten aan privacy en dus niet willen dat bijvoorbeeld de overheid veel gegevens verwerkt, maar tegelijkertijd wel zelf gemakkelijk (door middel van social media) allerlei persoonlijke informatie delen. Zie bijvoorbeeld: S. Barnes, A privacy paradox: social networking in the United States, Firstmonday, vol. 11, no. 9, 4 September 2006.] Zijn de gegevens eenmaal overgegaan in andere handen, dan kan weliswaar actie ondernomen worden, maar de zaak kan nooit meer volledig ongedaan gemaakt worden. Wat een dergelijke meldplicht echter mogelijk wel kan bewerkstelligen, is dat bedrijven alerter zullen reageren indien er een inbreuk heeft plaatsgevonden en wellicht zullen zij ook meer toezien (voor zover mogelijk) op het voorkomen van dergelijke lekken. In zoverre zou de meldplicht dus ook een preventieve werking kunnen hebben. Daar staat echter wel tegenover dat een inbreuk dan ook daadwerkelijk opgemerkt moet kunnen worden. In het huidige voorstel van wet is een verplichting opgelegd om iedere inbreuk te melden. De onmogelijkheid van detectie van elke inbreuk en het feit dat ook geringe inbreuken gemeld zouden moeten worden, zijn dan ook van meet af aan kritiekpunten op de meldplicht geweest.[Zie hierover bijvoorbeeld de reactie van KPN in de consultatieronde van het ministerie van Economische Zaken over het voorontwerp van wet tot implementatie van Richtlijnen 2009/136/EG en 2009/140/EG (versie 15 april 2010), verkrijgbaar via: http://www.internetconsultatie.nl/nrfimplementatie/.] KPN geeft aan dat het ‘lastig, zo niet onmogelijk’ is om altijd te achterhalen of er een veiligheidsinbreuk heeft plaatsgevonden die mogelijke gevolgen heeft voor de privacy van een individu. Caiway, Tele2 en Vodafone lopen te hoop tegen de onmogelijkheid om elk lek te ontdekken. In hun reactie schrijven zij dan ook dat ‘Indien een aanbieder veiligheidsmaatregelen heeft genomen die redelijkerwijs van hem kunnen worden verwacht, en hem een inbreuk op persoonsgegevens niet bekend is geworden, duidelijk zal moeten zijn dat hem niet kan worden verweten dat hij geen melding heeft gemaakt van de inbreuk.'[De reactie van Caiway, Tele2 en Vodafone in de consultatieronde van het ministerie van Economische Zaken over het voorontwerp van wet tot implementatie van Richtlijnen 2009/136/EG en 2009/140/EG (versie 15 april 2010), verkrijgbaar via: http://www.internetconsultatie.nl/nrfimplementatie/.] In haar samenvatting van de consultatie stelt het ministerie van Economische Zaken de betrokken partijen in zoverre gerust dat het aangeeft dat er gevallen denkbaar zijn waarin het niet melden van een datalek de aanbieder niet verweten kan worden. ‘Wat betreft mogelijke uitvoeringsproblemen wordt het volgende opgemerkt. Op grond van artikel 11.3 (Telecommunicatiewet – RM) dient de aanbieder van openbare elektronische communicatiediensten passende maatregelen te nemen ten behoeve van de veiligheid en beveiliging van de door hen aangeboden netwerken en diensten. Indien die beveiliging op orde is en er vindt een veiligheidsinbreuk plaats die waarschijnlijk zal leiden tot een aantasting van persoonsgegevens, en die inbreuk wordt niet opgemerkt, dan kan de aanbieder niet verweten worden dat hij de melding ervan heeft nagelaten. Een aanbieder behoeft en kan ook niet altijd op de hoogte zijn van het feit of als gevolg van een veiligheidsinbreuk er waarschijnlijk persoonsgegevens worden aangetast. Maar in veel gevallen zal de aanbieder voldoende aanwijzingen hebben dat bij het transport persoonsgegevens betrokken zijn.'[Consultatieverslag wetsvoorstel implementatie gewijzigd Europees regelgevend kader (NRF) in de Telecommunicatiewet, verkrijgbaar via: http://www.internetconsultatie.nl/nrfimplementatie/.] De laatste zin laat raden dat men niet zo heel snel zal aannemen dat een aanbieder niets verweten kan worden. Overigens kent ook de Wet bescherming persoonsgegevens voor de verwerker van persoonsgegevens de plicht om ‘passende technische en organisatorische maatregelen ten uitvoer [te leggen] om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking…’. Wel is deze eis strenger dan die welke is opgenomen in het wetsvoorstel van de wijziging Telecommunicatiewet, waar alleen gewezen wordt op ‘gepaste technische maatregelen’ en ‘versleuteling’.

Wat moeten organisaties regelen?

Elke organisatie – of het nu gaat om overheden of het bedrijfsleven – dient bij het verwerken van persoonsgegevens compliant te zijn met de Wet bescherming persoonsgegevens. Dit omvat onder meer het in kaart brengen van de informatiestromen binnen een organisatie (welke gegevens worden verwerkt en voor welke doeleinden), bezien of deze verwerkingen gemeld dienen te worden aan het College en indien er sprake is van zogenaamde Cross Border Data Transfer (gegevens worden buiten de EU/EER gebracht) moet rekening worden gehouden met een aantal specifieke vereisten, zoals bijvoorbeeld het verkrijgen van een vergunning daarvoor. Organisaties die deze zaken op orde hebben, zullen daardoor ook al een voorsprong hebben wat betreft de verplichtingen die voortvloeien uit de meldplicht. Door het op orde hebben van deze zaken zal een organisatie onder meer makkelijker kunnen aangeven wat de aard van de gegevens is en zal ze ook sneller een goed oordeel kunnen geven over de mogelijke impact van het datalek. Er dient immers een omschrijving van de gevolgen en de daarop genomen en nog te nemen maatregelen verstrekt te worden aan het College. In het verlengde daarvan is het noodzakelijk dat organisaties een zogenaamd ‘actieplan’ gereed hebben liggen voor het geval zich daadwerkelijk een datalek voordoet. Een dergelijk plan dient onder meer vast te leggen aan wie binnen de organisatie gemeld wordt dat er een onregelmatigheid heeft plaatsgevonden en welke maatregelen dientengevolge genomen moeten worden (denk daarbij aan het in kaart brengen van de gegevens die mogelijk bij het lek gecompromitteerd zijn geraakt, het gereed hebben van die concrete maatregelen en het uiteindelijke doen van de melding bij het College). Dit is te meer dringend daar een melding aan het College ‘onverwijld’ dient te geschieden.

Het adequaat beveiligen van persoonsgegevens die een organisatie verwerkt, is al onderdeel van de verplichtingen binnen de Wbp. Artikel 13 stelt dat een organisatie passende technische en organisatorische maatregelen ten uitvoer moet leggen tegen verlies of enige vorm van onrechtmatige verwerking. Daarbij moet rekening worden gehouden met de stand van de techniek (wat is feitelijk mogelijk?), de kosten (de kosten moeten proportioneel zijn), maar ook bijvoorbeeld de aard van de gegevens (zo geldt onder de Wbp een strenger regime voor het verwerken van gevoelige persoonsgegevens). Het begrip ‘passende’ maatregelen is niet nader ingevuld in de wet, alhoewel zoals vermeld wel enkele aanknopingspunten zijn gegeven waarmee rekening gehouden moet worden. Belangrijk in het licht van de meldplicht datalekken is het feit dat in het voorliggende voorstel voor de ‘smalle’ meldplicht opgenomen is dat, indien de gegevens cryptografisch versleuteld zijn, een lek weliswaar nog steeds gemeld dient te worden aan het College, maar dat daarbij niet tevens de personen om wier gegevens het gaat ingelicht hoeven te worden. Uit het oogpunt van bedrijfsrisico en dan met name wat betreft de publieke reputatie van een organisatie is het dus een groot pluspunt om de persoonlijke gegevens te versleutelen.

Een laatste belangrijk aspect wat betreft zaken rondom privacy en beveiliging van gegevens is dat het bij het puur technische op orde hebben van de beveiliging niet stopt. Zoals de Wet bescherming persoonsgegevens al aangeeft gaat het ook om het organisatorisch passend beveiligen van de gegevens die verwerkt worden. Privacy en beveiliging moeten dus ook ingebed raken in de organisatie zelf. Te denken valt dan aan het bevorderen van awareness onder werknemers (een e-learningcursus bij aanstelling of workshop voor huidige werknemers), het actief verspreiden en toetsen van het interne beleid (policies beschikbaar stellen op intranet en deze regelmatig updaten) en het beschikbaar hebben van procedures voor het geval zich een datalek voordoet. Daarnaast dienen de verantwoordelijkheden op de juiste plaats belegd te worden en dient er een veiligheidsbeleid te zijn.

Concluderend: is het nu een zorg of een zegen?

Waarschijnlijk een beetje van beide. De angst voor de publieke schandpaal doet menig bedrijf beven. Reputatieschade wordt over het geheel genomen toch vaak zwaarder gewogen dan de (geringe) boete van het College bescherming persoonsgegevens. Waarbij overigens opgemerkt moet worden dat de boetecapaciteit van het College inmiddels ook serieus ter discussie staat en naar verwachting in de herziening van de privacywetgeving op EU-niveau zal worden uitgebreid. Hoe dat eruit komt te zien, is nog niet te zeggen, maar een uitbreiding naar hogere boetemogelijkheden lijkt wel voor de hand te liggen. Ook de praktische uitvoerbaarheid – het moeten melden van elk lek – zal vermoedelijk enige kopzorgen opleveren (om nog maar te zwijgen van de kosten, een aspect waar ook verschillende aanbieders op wezen binnen de consultatieronde op het wetsvoorstel). Maar toch ook een zegen. In ieder geval voor het individu wiens gegevens met enige regelmaat op straat lijken te liggen. Openbaarheid noopt wellicht tot meer voorzichtigheid. Hoe een en ander in de praktijk daadwerkelijk zal uitpakken is vooralsnog gissen. Maar dat erover gepraat zal worden in 2011 staat in ieder geval vast. En … hopelijk zal ook serieus gewerkt worden aan die uitbreiding van de meldplicht. Datalekken komen namelijk echt niet alleen maar voor bij telco’s en ISP’s. Zo was recent ook de klant van McDonalds de klos ([Ring10a]), lekte het KLPD een fax met tapgegevens ([Zeng10a]), zagen miljoenen Amerikanen hun medische gegevens op straat liggen ([Ring10b]), lagen de medische gegevens van enkele Nederlanders bij de Kringloop ([Zeng10b]), en werd een Amerikaanse bank aangeklaagd omdat zij een datalek had geprobeerd te verdoezelen ([Brow10]).

Hoe kunnen organisaties zich nu voorbereiden op die aankomende meldplicht? Door er in ieder geval voor te zorgen dat:

er alles aan gedaan is de beveiliging op orde te hebben (heeft u de kennis niet zelf in huis, dan loont het de moeite deze in te huren), daarnaast: versleutelde data hebben in beginsel het voordeel dat een mogelijk lek niet aan de personen (klanten vaak) om wier data het gaat, gemeld hoeft te worden;
er besef is dat beveiliging niet alleen maar het technisch afdichten van de systemen is (denk aan de plicht binnen de Wet bescherming persoonsgegevens om ook organisatorisch de zaken op orde te hebben);
er gewerkt wordt aan inrichting van processen en richtlijnen over hoe te handelen in geval zich een datalek voordoet, dit inclusief het op orde hebben van up-to-date informatie, zeker gezien het feit dat een lek ‘onverwijld’ gemeld moet worden en daarbij ook eisen gesteld zijn wat betreft welke informatie paraat moet liggen.

Literatuur

[Brow10] D. Browning, U.S. bank allegedly concealed data breach, Star Tribune, 7 december 2010.

[KPMG10] KPMG Data Loss Barometer, november 2010, www.datalossbarometer.com.

[Ring10a] T. van Ringelestijn, Hackers stelen data McDonalds-klanten, Webwereld, 13 december 2010.

[Ring10b] T. van Ringelestijn, Miljoenen medische gegevens Amerikanen gelekt, Webwereld, 26 november 2010.

[Zeng10a] R. Zenger, Datalek: KLPD lekt fax met tapgegevens, 25 november 2010, Zwartboek Datalekken, BoF.

[Zeng10b] R. Zenger, Datalek: Medische gegevens in Kringloopwinkel, 13 december 2010, Zwartboek Datalekken, BoF.

Older posts

Newer posts