We live and work in a high-tech, interconnected world that is seeing increases in the volume and sophistication of cyberattacks. In order to function safely in this technology-driven, digital world, we must have strong cybersecurity controls. But how do we know if we have the right controls or if our controls are functioning as planned?
Because of the need for audit and assurance programs and processes around cybersecurity, ISACA has developed a new IS audit/assurance program, Cybersecurity: Based on the NIST Cybersecurity Framework. The goal of this program is to provide organizations with a formal, repeatable way to validate cybersecurity controls.
The program is based on the NIST Cybersecurity Framework and is built around the following five critical cybersecurity activities:
Identify – Determine if the systems, assets, data and capabilities critical to cybersecurity have been identified and are understood by the organization. Process sub-areas include asset management, business environment, governance, risk assessment and risk management strategy.
Protect – Review cybersecurity safeguards designed to limit the impact of potential events. Process sub-areas include access control, awareness and training, data security, information protection processes and procedures, maintenance, and protective technology.
Detect – Assess activities designed to identify the occurrence of cybersecurity events. Process sub-areas include anomalies and events, security continuous monitoring and detection processes.
Respond – Evaluate action plans to take after learning of a security event. Process sub-areas include response planning, communications, analysis, mitigation and improvements.
Recover – Analyze plans for resilience and the timely repair of compromised capabilities and services. Process sub-areas include recovery planning, improvements and communications.
The program is offered as a Microsoft Excel file with columns created so users can define controls to be tested (including frequency and results), as well as add references and comments. Testing steps have been identified for each NIST Cybersecurity Framework functional subcategory. These subcategories are labeled “Controls” in the program.
In addition, controls are referenced to COBIT 5 and ISO/IEC 27001:2013, making it easier for professionals to integrate the program into existing frameworks and/or audit programs.
In today’s digitally connected world, it seems many have an increasingly myopic view, as it’s all too easy to get caught up in what’s important to individuals instead of collective needs. As such it was very interesting to attend a CNBC debate session at the World Economic Forum Annual Meeting in Davos, entitled “2016: The Year Fintech Dominated Disruption”.
The concept seems an oxymoron: as technology evolution continues exponentially, I wonder what comes after domination? One panelist commented that, whilst many consumers will experiment with new tech that includes financial transactions, the financial investment is typically trivial, and the reality is that consumers will come back to the organisations they have trusted for decades in which to invest their entire capital wealth.
At the same time, there was acceptance that retail technology transition had overtaken the financial organisations, so they are now pushing for innovation. This drove much of the broader discussion on where and how such innovation is driven. One bank highlighted that today they are working with over 70 different financial technology companies through the partnerships, joint ventures or acquisitions they have made. Whether these are evolutionary or transformational, I would speculate all of the above.
Financial regulation has always seemed to be a constraining factor to fintech innovation, from my perception, but it was highlighted that more regulators are now starting to support small sandbox environments to allow more dynamic application of new environments to test fintech concepts. It was very interesting to hear the debate, which effectively challenged innovation versus trust, and given this, it was surprising cybersecurity didn’t enter the discussion further.
On one hand, fintech looks for new methods to deliver old services via such tools as blockchain, which can provide a new architecture to allow greater transaction volumes to be processed and stored, with timestamped and linked data blocks for a permanent verification trail. On the other hand, fintech also creates the opportunity for far more complex transactional processes; indeed there were predictions that machine-to-machine transactions will someday outweigh the number of human-based financial transactions.
There is an old adage that you’re only as strong as your weakest link, so considering what, in finance, looks likely to become a transaction process with greater volume and complexity, the need to transform how we secure platforms, applications and processes is clear. Typically, security is applied at each level in isolation, creating fragmented, high-volume and partial indications that then rely on human analysis in order to validate whether there is a cyber incident.
All too often cybersecurity comes after innovation, and while fintech is undoubtedly disrupting how transactions occur and consumers are pushing banks to evolve, cybersecurity requirements are only going to become more complex. It’s important to start to connect and automate the cybersecurity capabilities across the payment ecosystem, in collaboration with banks and fintech providers, to create security-aware, integrated platforms that are as automated as the transactions being processed. Only then can cybersecurity, and the required trust that goes with it, keep pace in this disruptive space.
The Cloud Security Alliance’s Quantum-Safe Security (QSS) Working Group announces their latest release with the Quantum-Safe Security Glossary. The QSS Working Group was formed to address key generation and transmission methods and to help the industry understand quantum-safe methods for protecting networks and data. The working group is focused on long-term data protection amidst a climate of rising cryptanalysis capabilities. As the working group continues to produce documents to address concerns in a quantum world, the opportunity to share terms to provide a starting point to learn more about quantum-safe security.
This glossary is a collective contribution of the QSS Working Group to increase quantum-safe security awareness, and includes a compilation of common terms used in the world of quantum-safe cryptography. The document was created with the working groups input and went through an open peer review for collaboration and completeness. However, quantum-safe cryptography is a very dynamic issue, prone to unpredictable patterns and instability. In anticipation of these characteristics, the QSS Working Group plans to update this document from time to time moving forward. For more information on the Quantum-Safe Security Working Group, please visit https://cloudsecurityalliance.org/group/quantum-safe-security/.
The Internet of Things (IoT) is quickly becoming a highly populated digital space. Two popular types of IoT items are the Amazon Echo personal helper, that answers to “Alexa” (or “Echo” or “Amazon”), and the Google Home personal helper, that responds to “OK” (or “Google”). These highly proclaimed smart gadgets are always listening; as are generally all similar types of smart gadgets and toys.
Listening can quickly change to recording and storing the associated files in the vendors’ clouds because of how these devices are engineered. Let’s consider the privacy implications of how those recordings are made, where they are stored, how the recordings are used, and who has access to the recordings.
Amazon and Google both claim that their smart personal assistant devices do not keep any data that they are listening to before those keywords that trigger the recordings. However, here are just a few important privacy-impacting facts:
All the sounds going on within the vicinity are also part of the recordings, along with a large amount of meta data, such as location, time, and so on.
The recordings will be kept indefinitely until consumers take it upon themselves to take actions and request the recordings be deleted.
Data, possibly including recordings (this topic is not directly addressed by Amazon or Google), may be shared with a wide range of third parties, and both vendors state they have “no responsibility or liability” for how that data is used by the third parties.
There are other privacy issues, of course. But, for now, let’s focus on these, which are significant on their own.
Privacy protections currently require manual intervention
While the Amazon and Google privacy policies each boast of privacy protections, those policies fall short of providing full explanation for full privacy protections specifically for Alexa and Home. And for the most part, consumers must take actions to protect their privacy, particularly for the issues listed previously. For example, users must, at a minimum, take the following six actions to establish a minimum level of privacy protections for themselves:
Physically turn off the devices to keep them from recording everything in the vicinity. The devices do not turn off by themselves. These devices have been known to respond to words other than the keywords, and even order items as a result. By keeping the devices on all the time, you risk having private conversations recorded and accessed by whomever has access to the vendors’ clouds. Users should keep smart devices turned off when they have guests over and when they simply do not plan to use these devices.
Set a password and change default passwords and wake words. Choose ones that are different from your other passwords, that are long and complex, and that are not composed of words found in any type of dictionary or are commonly spoken.
Opt out of data-sharing. Generally, for most businesses in the U.S., if you don’t opt-out of data-sharing, you will be implicitly allowing the manufacturer to give, or even sell, your data to unlimited numbers of third parties; e.g., marketers, researchers and other businesses. You will then have no control or insights into how the data about YOU is used and shared by THEM.
Use encryption. Turn on encryption for data transmissions and data in storage. Most are off by default. Amazon and Google generally state they encrypt all data in transit and in the cloud for all their services and products. However, disappointingly, neither give an option to encrypt the in-home device data storage.
Read the privacy policy. If any IoT device vendor does not have a privacy policy, then don’t buy from them! This is an indication of either a bogus site, or of a site that does not build security or privacy into their products.
Delete your data from the cloud. Don’t forget that all the audio recorded, and the associated meta data, will be kept within the Amazon and Google cloud systems forever – unless you take the initiative to delete it. And since that data is being accessed by a wide range of unknown third parties, you don’t want the information to be used to violate your privacy or result in privacy harms.
Effective privacy protections must be built in and automatic
These manual actions need to be taken for current versions of smart personal gadgets to protect privacy in the short-term. However, the time is long overdue for privacy protections and security controls to be engineered into every type of smart device available to consumers. The amount of data collected and the potential privacy harms that could occur with that data are too great to allow IoT vendors to simply take a few incomplete actions that only start, and do not complete, the implementation of all privacy protections that are necessary to protect the privacy and security those using the devices.
For example, to address the issues discussed here, Google and Amazon could have engineered the devices so that:
Device settings could be set by consumers to automatically turn the devices off without physically doing so.
Authentication was required and had to be strong.
Data would not be shared with third parties without explicit permission as a device setting from the associated consumers.
Data in storage on the device was automatically and strongly encrypted.
Privacy notices could be accessed (possibly via audio) through the device.
Consumers could have settings for automatic deletion from the cloud.
Over the past couple of years, I’ve chatted with my friends at CW Iowa Live about the privacy issues involved with these IoT devices. For more information on this topic beyond this blog post, you can listen to them here and here.
Utilize ISACA Privacy Principles to build privacy into processes
So how should engineers approach building privacy controls into IoT devices? Use new ISACA privacy resources! I am grateful and proud to have been part of the two ISACA International Privacy Task Force groups, both led by Yves Le Roux, since 2013, and to have been the lead developer authoring the newly released ISACA Privacy Principles and Program Management Guide (PP&PMG), incorporating the recommendations and input of the International Task Force members, as well as a complementary privacy guide targeted for publication in mid-2017.
The ISACA PP&PMG outlines the core privacy principles that organizations, as well as individuals, can use to help ensure privacy protections. These privacy principles can be used by engineers to build the important privacy and security controls into IoT devices right from the beginning of the initial design phase, and use them all the way through the entire product development and release lifecycle. Aligned and compatible with international privacy models and regulatory frameworks, the ISACA Privacy Principles can be used on their own or in tandem with the COBIT 5 framework.
The second ISACA privacy guide that will be released this year will include many examples throughout the entire data lifecycle and a detailed mapping of where to incorporate privacy controls within the COBIT 5 control framework component.
Yes, you did read the headline right. It is the conclusion of a United Kingdom’s Government review (Cyber security regulation and incentives review) published right at the end of 2016. Here, the UK Government concludes that the EU General Data Protection Regulation (GDPR), with its reporting requirements and financial penalties represents a significant call to action, so no further regulation is required at this time.
This decision is to be applauded for four reasons.
First, many UK-based organisations are also having to prepare for the European Union Network Information Security (NIS) Directive. Both NIS and GDPR are placing significant resource and financial burdens on organisations as they review and enhance their processes, security controls (managerial, technical and procedural) and approaches to data collection and storage.
Second, the review’s authors recognise that regulation encourages a ‘tick-box mentality’ or ‘compliance culture’, in that organisations will do what is stated in the regulation and go no further. Adopting this sort of culture runs against the risk-based approach that many cybersecurity professionals both favour and use on a day-to-day basis; it also reduces the scope for the pro-active approach that we are all trying to develop and instil in our organisation’s security programmes to deal with the dynamic and ever changing cyber risk landscape.
Third, regulation of any kind adds to the cost of doing business – and many sectors of the economy face an ever-increasing tide of regulation. The review stated that mandating specific controls would not work as they would become out of date very quickly, which is another welcome statement.
Finally, it makes clear that organisations should manage their own risk in respect of sensitive data and online presence and that as each organisation’s IT is unique, individual companies are best placed to determine the controls appropriate for their organisation.
So what does it mean for cybersecurity professionals?
For those of us in the UK, it allows us to concentrate on meeting the requirements of GDPR (and where relevant, the NIS Directive). We should highlight the results of this review – and the emphasis placed on GDPR – to our Boards, our CIOs and legal functions to help further their support for GDPR projects and to help them plan their compliance programmes.
For those outside of the UK, it’s worth sharing this document with your regulators, government representatives and CERTs to show how the decision was reached and the reasoning behind that decision. For any multinational, it sends a clear signal that compliance to GDPR is a prerequisite for doing business in the UK and provides a solid basis to demonstrate cyber security.
Finally, the review is the strongest signal to us as cybersecurity professionals that we are being trusted to get on with the job and deliver. We have a window of opportunity to show that we can deliver effective cyber security risk management and compliance with GDPR. It’s worth noting, however, that the UK Government has reserved the right to re-examine whether further regulation is required in the future. A massive breach, or failure to embrace the requirements of GDPR across UK industry, could be two scenarios that trigger another review and new regulation.
The (ISC)2 EMEA Advisory Council has established a GDPR task force of certified members actively involved in implementing GDPR. The aim is to track, curate and share front-line experience with the regulation. Members interested in contributing to the effort are encouraged to contact EAC co-chair yleroux@eac.isc2.org, or Adrian Davis (adavis@isc2.org).
