If you are involved in creating, maintaining, operating or acquiring risk-appropriate software, this short blog about the recent wannacry ransomware exercise is worth reading.
The Cloud Security Alliance published “The Treacherous 12 – Cloud Computing Top Threats in 2016” last year. I just saw it cited in a security conference presentation and realized that I had not shared this reference. For those involved in decision-making about risk management of their applications, data, and operations, this resource has some value. If you have not yet experienced a challenge to host your business in “the cloud”** it is likely you will in the future.
In my opinion, the Cloud Security Alliance is wildly optimistic about the business and compliance costs and the real risks associated with using shared, fluid, “cloud” services to host many types of global financial services business applications & non-public data. That said, financial services is a diverse collection of business activities, some of which may be well served by credible “cloud” service providers (for example, but not limited to, some types of sales, marketing, and human resource activities). In that context, the Cloud Security Alliance still publishes some content that can help decision-makers understand more about what they are getting into.
“The Treacherous 12 – Cloud Computing Top Threats in 2016” outlines what “experts identified as the 12 critical issues to cloud security (ranked in order of severity per survey results)”:
- Data Breaches
- Weak Identity, Credential and Access Management
- Insecure APIs
- System and Application Vulnerabilities
- Account Hijacking
- Malicious Insider
- Advanced Persistent Threats (APTs)
- Data Loss
- Insufficient Due Diligence
- Abuse and Nefarious Use of Cloud Services
- Denial of Service
- Shared Technology Issues
For each of these categories, the paper includes some sample business impacts, supporting anecdotes and examples, candidate controls that may help address given risks, and links to related resources.
If your role requires evaluating risks and opportunities associated with “cloud” anything, consider using this resource to help flesh out some key risk issues.
**Remember, as abstraction is peeled away “the cloud” is an ecosystem constructed of other people’s “computers” supported by other people’s employees…
Cloud Security Alliance:
“The Treacherous 12 – Cloud Computing Top Threats in 2016”
I received an excellent reminder about protecting secrets from a developer this morning. His advice included:
In the course of development work, many of us need to encode or encrypt strings. He had just bumped into a situation where teams were using an Internet-available, public service to base 64 encode OAuth key/secret pairs. These OAuth “secrets” are used all over the Internet to authenticate against web service interfaces. Too often they are static/permanent strings — which means that once stolen they are useful to anyone, hostile or otherwise, for long periods of time. This type of authentication credential must be very carefully protected throughout its entire life-cycle.
[Please stick with me even if you are not familiar with base 64 or OAuth, because this is broadly reusable advice]
The specific site is not really important as it could have been one of thousands of other free data encoding/encrypting sites.
The risk issue is associated with the fact that the “free” encoding service cloud site knows the client’s source IP address (plus other endpoint/user-identifying metadata) and the secrets that the user inputs. Using that information, they can infer (with some confidence) that a given company is using these secrets, and can sometimes also infer what the secrets are used for by the structure of the inputs. Nothing on the Internet is truly free. We need to assume that these sites earn revenue by monetizing what they learn. Cyber-crime is a business, and it is often less expensive to buy information about specific or classes of candidate targets than to independently perform the initial reconnaissance. So we should expect that some percentage of what free sites learn ends up as inputs to cyber-crime planning and activities. In that context, our secrets would not remain secret — and our risks would be elevated. In addition, extruding secrets in this way would also violate company policy at every global Financial Services enterprise.
Lucky for all of us, there are easy alternatives to using Internet-available public services to encode/encrypt our secrets.
Encoding can be as simple as a PowerShell or Python one-liner:
python -c "import base64; encoded=base64.b64encode(b'mySecret'); print encoded;"
Or you can use any other development language of choice to easily assemble a utility to encode secrets. This is not technically difficult or especially risky.
Encrypting safely is a greater challenge. Understand your goals first. Once you know what you need to achieve, you can work with a professional to select a cryptosystem and coding/operational processes that should have a chance of meeting those goals. Cryptography can go wrong. Do not attempt to invent your own.
I have a sticker on my laptop reminding me that “The cloud is just other people’s computers.” (from StickerMule) There is no cloud magic. If you extend your global Financial Services operations into the cloud, it needs to be clearly and verifiably aligned with your risk management practices, your compliance obligations, your contracts, and the assumptions of your various constituencies. That is a tall order. Scan the rest of this short outline and then remember to critically evaluate the claims of the hypesters & hucksters who sell “cloud” as the solution to virtually any of your challenges.
Amazon reminded all of us of that fact this week when maintenance on some of their cloud servers cascaded into a much larger 2 hour service outage.
No data breach. No hack. Nothing that suggests hostile intent. Just a reminder that the cloud is a huge, distributed pile of “other people’s computers.” They have all the hardware and software engineering, operations, and life-cycle management challenges that your staff find in their own data centers. A key difference, though, is that they are also of fantastic scale, massively shared, and their architecture & operations may not align with global Financial Services norms and obligations.
Amazon reported that the following services were unavailable for up to two and half hours Tuesday Morning (28 Feb, 2017):
- S3 storage
- The S3 console
- Amazon Elastic Compute Cloud (EC2) new instance launches
- Amazon Elastic Block Store (EBS) volumes
- AWS Lambda
This resulted in major customer outages.
Here is how Amazon described the outage:
- “…on the morning of February 28th. The Amazon Simple Storage Service (S3) team was debugging (a billing system) issue…”
- “At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process.”
- “Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended.”
- “The servers that were inadvertently removed supported two other S3 subsystems.”
- “One of these subsystems, the index subsystem, manages the metadata and location information of all S3 objects in the region. This subsystem is necessary to serve all GET, LIST, PUT, and DELETE requests.”
- “The second subsystem, the placement subsystem, manages allocation of new storage and requires the index subsystem to be functioning properly to correctly operate. The placement subsystem is used during PUT requests to allocate storage for new objects.”
- “Removing a significant portion of the capacity caused each of these systems to require a full restart.”
- “While these subsystems were being restarted, S3 was unable to service requests.”
- “Other AWS services in the US-EAST-1 Region that rely on S3 for storage, including the S3 console, Amazon Elastic Compute Cloud (EC2) new instance launches, Amazon Elastic Block Store (EBS) volumes (when data was needed from a S3 snapshot), and AWS Lambda were also impacted while the S3 APIs were unavailable.”
There is no magic in the cloud. It is engineered and operated by people. Alignment between your corporate culture, your corporate compliance obligations, your contractual obligations, and those of your cloud providers is critical to your success in global Financial Services. If those cloud computers and the activities by armies of humans who manage them are not well aligned with your needs and obligations, then you are simply depending on “hope” — one of the most feeble risk management practices. You are warned — again.
What do you think?
“The embarrassing reason behind Amazon’s huge cloud computing outage this week.”
By Brian Fung, March 2
“Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region.”
The research team at security & risk data aggregator (and more) Risk-Based Security (RBS) published a couple of their observations this month — observations that should be a reminder to all of us involved in global Financial Services risk management. RBS catalogs & analyzes thousands of breaches every year. They suggest that ad-hoc, personality-based, or other types of company-unique security practices put companies at a self-inflicted and avoidable level of risk. RBS researchers summarize their findings into a couple central themes:
- “Breaches can happen at even the most security-conscious organizations.”
- “The tenacity and skill of attackers when it comes to searching out weaknesses in organizational practices and processes is unrelenting.”
There are a couple key components to their follow-on recommendation:
- Employ a methodical and risk-based approach to security management, where risk assessments incorporate both:
- The organization’s security practices, and
- Downstream risk posed by vendors, suppliers and other third parties.
To address these risks and add structure to day-to-day risk management work, RBS researchers recommend that we:
- Define security objectives and
- Select and implement security controls.
The content of the memo describing RBS research observations is useful at the most high levels as a reminder in global Financial Services. While this seem a little like recommending we all continue to breath, eat well, and sleep enough. Their guidance to leverage mature security frameworks “to create robust security programs based on security best practice” is a long bumper sticker. In Financial Services at global scale, we all know that and our various constituencies regularly remind us of those types of requirements. Sometimes they even show up in our sales literature, contracts, and SEC filings.
Bumper stickers may still have their place. RBS observations and recommendations may not be what we need for implementation, but they can help with our elevator speeches & the tag-lines required in a number of frequently encountered risk management interactions.
Here is one way to use summarize their observations and recommendations:
Breaches continue to happen. Attackers are tenacious and unrelenting. Employ risk-appropriate levels of rigor and risk-based prioritization in the application your security practices, as well as in downstream risk posed by vendors, suppliers and other third parties.
“Risk Based Security, NIST and University of Maryland Team Up To Tackle Security Effectiveness.”
February 17, 2017; By RBS
Another key message in the blog was to highlight a joint research project by “NIST’s Computer Security Resource Center and the University of Maryland, known as the Predictive Analytics Modeling Project (http://csrc.nist.gov/scrm/pamp-assessment-faqs.htm). The aim of the project is to conduct the primary research needed in order to build tools that can measure the effectiveness of security controls.” The project web site also says their mission includes seeing “how your organization compares to peers in your industry.” For more on this project see “CyberChain” at: https://cyberchain.rhsmith.umd.edu/.
We all need to work with leaders and other influencers who hold “compliance” as their prime (sometimes, only) risk management driver. Sure, that is tiring and sometimes disheartening, but they are not going away… In the course of your efforts to advance effective information and operations security motivating these individuals can be a challenge. Because large scale financial services enterprises in the United States do business across the country, it is sometimes helpful to be able to demonstrate the scope of legislation (not regulation) that applies to various aspects of information and cyber security. Below is a collection of lists of laws on related information security topics from the National Conference of State Legislatures (http://www.ncsl.org/aboutus.aspx) that may help you on that front. I’ve included a couple of global resources as well, but that information is far more limited than is available to me about U.S. state laws.
At the story-telling level, one might use this list to demonstrate why it is critical to create, acquire, evolve and maintain ________ (this may be context-specific, use whatever is applicable: software, networks, servers, endpoints, databases, appliances, etc…) that are audit-ready, resilient and resistant to attack, and that protect sensitive resources & transactions while delivering the intended levels of service while under attack. I am not a lawyer and this is not legal advice! But I believe given the scope and complexity of the laws involved, along with the velocity of change, attempting to achieve and maintain tight compliance alignment with all applicable laws & regulations would be vastly more expensive than focusing most of our creativity & energy on fielding safe-enough software, infrastructure, and operations.
Sure, laws, regulations, and the professionals who focus on them are critically important in Financial Services. That does not make them the center-of-the-universe for information security. Safe software, safe infrastructure, and safe operations are expected by all our constituencies and these characteristics also should satisfy information security-relevant compliance obligations. This seems like an achievable goal. Mapping every relevant law and regulation to every facet of every application and all aspects of our infrastructure and its operations seems impractical and unbusinesslike.
What do you think?
List of U.S. Security Breach Notification Laws:
Forty-seven states, the District of Columbia, Guam, Puerto Rico and the Virgin Islands have enacted legislation requiring private, governmental or educational entities to notify individuals of security breaches of information involving personally identifiable information.
A running list of U.S. security breach-related legislation by year (2010 to present):
List of U.S Data Disposal Laws:
At least 31 states and Puerto Rico have enacted laws that require entities to destroy, dispose, or otherwise make personal information unreadable or undecipherable.
List of U.S. Identity Theft Laws:
Identity theft occurs when someone uses another person’s personally identifying information, like a person’s name, Social Security number, or credit card number or other financial information, without permission, to commit fraud or other crimes.
This chart summarizes the identity theft criminal penalties, restitution and identity theft passport laws. Every state has a law regarding identity theft or impersonation. Twenty-nine states, Guam, Puerto Rico and the District of Columbia have specific restitution provisions for identity theft. Five states—Iowa, Kansas, Kentucky, Michigan and Tennessee—have forfeiture provisions for identity theft crimes. Eleven states—Arkansas, Delaware, Iowa, Maryland, Mississippi, Montana, Nevada, New Mexico, Ohio, Oklahoma and Virginia—have created identity theft passport programs to help victims from continuing identity theft.
List of U.S. Cybersecurity Legislation for 2016:
Cyber threats have enormous implications for government security, economic prosperity and public safety. States are addressing cybersecurity through various approaches, such as:
- Requiring government or public agencies to implement security practices
- Offering incentives to the cybersecurity industry
- Providing exemptions from public records laws for security information
- Creating cybersecurity commissions, studies or task forces
- Promoting cybersecurity education.
List of U.S. Computer Crime Statutes:
Computer crime laws encompass a variety of actions that destroy or interfere with normal operation of a computer system including hacking, unauthorized access, and malware, among others.
List of U.S. State Laws Associated with Phishing:
Phishing is a scam where fraudsters send spam or text messages or create deceptive websites to lure personal or financial information from unsuspecting victims.
U.S. State Spyware Laws
Last update: 12/3/2015
Spyware, also sometimes called adware, is software that can track or collect the online activities or personal information of Web users, change settings on users computers, or cause advertising messages to pop up on users’ computer screens. Web users are often unaware that spyware has been downloaded to their computers, and even when found, it can be very difficult to remove.
Twenty states, Guam and Puerto Rico have laws targeting spyware. Other states have laws that address computer crime, fraudulent or deceptive practices or identity theft and that possibly could apply to some practices involving spyware.
Perkins Coie’s list of U.S. State Security Breach Notification Laws:
(Last Revised June 2016)
Perkins Coie’s Privacy & Security practice maintains a comprehensive chart that summarizes state laws regarding security breach notification. The chart is for informational purposes only and is intended as an aid in understanding each state’s sometimes unique security breach notification requirements. Lawyers, compliance professionals, and business owners have told Perkins Coie that the chart has been helpful when preparing for and responding to data breaches.
This resource includes more detail than most of the links listed above.
DLA Piper “Data Protection Laws of the World”
Interactive Map Of Notification Status and more.
Interactive map highlighting breach notification rules and regulations (per country). The colors of the countries below represent a data breach risk index. Red is the highest, orange is high, yellow is elevated, blue is general, and green is low risk.
There is also an on-demand PFD version of “Data Protection Laws of the World” available from DLA Piper at:
When downloaded on November 29, 2016, this was a 510 page document covering the following 98 countries: Angola, Argentina, Australia, Austria, Belarus, Belgium, Bosnia and Herzegovina, British Virgin Islands, Bulgaria, Canada, Cape Verde, Cayman Islands, Chile, China, Colombia, Costa Rica, Brazil, British, Bulgaria, Canada, Cape, Cayman, Chile, China, Colombia, Costa, Croatia, Cyprus, Czech Republic, Denmark, Egypt, Estonia, Finland, France, Germany, Ghana, Gibraltar, Greece, Guernsey, Honduras, Hong Kong, Hungary, Iceland, India, Indonesia, Ireland, Israel, Italy, Japan, Jersey, Latvia, Lesotho, Lithuania, Luxembourg, Macau, Macedonia, Madagascar, Malaysia, Malta, Mauritius, Mexico, Monaco, Montenegro, Morocco, Netherlands, New Zealand, Nigeria, Norway, Pakistan, Panama, Peru, Philippines, Poland, Portugal, Romania, Russia, Saudi Arabia, Serbia, Seychelles, Singapore, Slovak Republic, South Africa, South Korea, Spain, Sweden, Switzerland, Taiwan, Thailand, Trinidad and Tobago, Turkey, UAE – Dubai (DIFC), UAE – General, Ukraine, United Kingdom, United States, Uruguay, Venezuela, and Zimbabwe.
This page below provides a brief summary of the requirements of each of the 47 U.S state data breach notification laws as of August 2014.
It is still important to deliver messages that influence…
Good visuals have a way of imprinting, and of adding context that sticks with a good argument.
A collection of researchers, along with some design & coding help just released an update to their “World’s Biggest Data Breaches” graphic. It uses color, size, location along a timeline, and additional interactive data to document selected data loss greater than 30,000 records between 2004 and October 2016.
It seems like one of those resources that will be useful in a number of contexts. [For example: Have you ever been asked “Why do I have to change my password — again…? — One answer: Because in a world where humans too often reuse passwords across systems, passwords are no longer ‘durable.’ Look at this illustration to see how many have been stolen over the last decade…]
Use it to help goose up your risk management stories:
“World’s Biggest Data Breaches — Selected losses greater than 30,000 records.”
(updated 15th Oct 2016 Version 1.095)
Research: Miriam Quick, Ella Hollowood, Christian Miles, Dan Hampson; Design & concept: David McCandless; Code: Tom Evans.
A static version from early 2015: http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-static/