​The Treacherous 12 – Cloud Computing Top Threats in 2016

April 25, 2017

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)”:

  1. Data Breaches
  2. Weak Identity, Credential and Access Management
  3. Insecure APIs
  4. System and Application Vulnerabilities
  5. Account Hijacking
  6. Malicious Insider
  7. Advanced Persistent Threats (APTs)
  8. Data Loss
  9. Insufficient Due Diligence
  10. Abuse and Nefarious Use of Cloud Services
  11. Denial of Service
  12. 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…

REFERENCES:

Cloud Security Alliance:
https://cloudsecurityalliance.org

“The Treacherous 12 – Cloud Computing Top Threats in 2016”
https://downloads.cloudsecurityalliance.org/assets/research/top-threats/Treacherous-12_Cloud-Computing_Top-Threats.pdf


Another Example of How Cloud eq Others Computers

March 2, 2017

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:

  1. “…on the morning of February 28th. The Amazon Simple Storage Service (S3) team was debugging (a billing system) issue…”
  2. “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.”
  3. “Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended.”
  4. “The servers that were inadvertently removed supported two other S3 subsystems.”
  5. “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.”
  6. “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.”
  7. “Removing a significant portion of the capacity caused each of these systems to require a full restart.”
  8. “While these subsystems were being restarted, S3 was unable to service requests.”
  9. “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?

REFERENCES:
“The embarrassing reason behind Amazon’s huge cloud computing outage this week.”
https://www.washingtonpost.com/news/the-switch/wp/2017/03/02/the-embarrassing-reason-behind-amazons-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.”
https://aws.amazon.com/message/41926/


Protect Your USB

September 19, 2016

Physical and logical PC controls still matter.

Just one more reason to resist the shared madness of “bring your own device” and/or “anywhere/anytime/any-endpoint” in global Financial Services.  We hold trillions of dollars for our customers (under the guise of a broad and evolving range of relationships)!  To add value to those relationships, we turn that money into units that are inter-business (and Internet) friendly to enable complex webs of financial transactions and services.  The concentration of “cash” and its transformation into bits results in an attractive target for hostile parties of many types.  How could endpoint anarchy ever be a risk-appropriate behavior for any but a microscopically few roles within our ranks?  It seems like something we should expect to fail the “reasonable person” test.

I was just catching up on some of my random reading and bumped into this demonstration of Windows credential stealing with just 15 seconds of access to a PC’s USB port.

15 seconds of social engineering is not that hard to pull off, so all you have left are serious controls administering the use of your USB ports, physically destroying your USB ports (yes, that is a serious option), along with multi-layer physical & logical security to the location of the PC at any given time.

Take a look st the video below along with the supporting paper.  Then voice your professional opinion and conscience wherever appropriate to resist elevated risk endpoint behaviors.  And if your role permits, ensure that your Financial Services organization has the goals and resources to effectively deal with attacks like the ones enabled by this automated, USB enabled assault.

REFERENCES:

15 Second Password Hack, Mr Robot Style
Video:
https://www.hak5.org/episodes/season-21/hak5-2101-15-second-password-hack-mr-robot-style
Supporting Paper
https://www.hak5.org/blog/15-second-password-hack-mr-robot-style


Use care when describing how you do Financial Services security

March 3, 2016

Use care when describing how you do your Financial Services security.  This seems especially relevant as some in our industry attempt to drive down costs by extending their operations into low cost consumer-heritage cloud services and onto other types of opaque Internet platforms of all kinds.  Consultants, pundits, analysts, and hucksters are all attempting to make a living by selling schemes that incorporate one or many of these options.  What they tend to omit, are the impacts that their ideas may have on the truthfulness of your public and contractual security assurances.

The Consumer Financial Protection Bureau (CFPB) just fined Dwolla $100,000 U.S. for misleading users about the company’s data security practices.  In addition, Dwolla must report virtually all security-related activities to the CFPB and request permission for certain types of security changes for the next 5 years.  The CFPB also put the Dwolla Board of Directors on notice that they must demonstrate more intense and more regular involvement in and oversight of Dwolla security measures and their effectiveness.

The CFPB also required Dwolla to implement a long list of measures to improve the safety and security of its operations and the consumer information that is stored on, or transmitted through, its network(s). [see pages 12-13 for just the initial summary]

A key mandate seems to be that these security measures must evolve as Dwolla grows.  The CFPB wrote that Dwolla must protect the confidentiality, integrity, and availability of sensitive consumer information with “administrative, technical, and physical safeguards appropriate to Respondent’s size and complexity, the nature and scope of Respondent’s activities, and the sensitivity of the personal information collected about consumers.”  So this is not a simple once-and-done mandate at all.

Dwolla operates an online payments-transfer network.

The CFPB said Dwolla misrepresented the security of its platform, which collects users’ personal information at account set up.  All Financial Services enterprises collect users’ personal information at account setup…

The CFPB wrote that Dwolla had failed to:

  • Adopt and implement data-security policies and procedures reasonable and appropriate for the organization;
  • Use appropriate measures to identify reasonably foreseeable security risks;
  • Ensure that employees who have access to or handle consumer information received adequate training and guidance about security risks;
  • Use encryption technologies to properly safeguard sensitive consumer information; and
  • Practice secure software development, particularly with regard to consumerfacing applications developed at an affiliated website, Dwollalabs. (Note: Under this heading, the CFPB also included ending the use of customer information in the non-production environment.)

Would your Financial Services organization hold up against a thorough review of these two areas of secure operations?

In response, Dwolla wrote:

Dwolla was incorporating new ideas because we wanted 
to build a safer product, but at the time we may not have 
chosen the best language and comparisons to describe 
some of our capabilities. It has never been the 
company’s intent to mislead anyone on critical issues 
like data security. For any confusion we may have caused, 
we sincerely apologize.

In that blog entry, they go on to describe how they implement security today.  They use careful words to describe their current status and strategy.

Dwolla has been an optimistic, agile, cloud-friendly, fast-evolving financial services specialist company for years.  The CFPB fine is a signal that optimism and its close relative in some approaches to ‘risk management‘ — hope — are not going to be tolerated as effective protections for customer personal information.  I understand that we must always attempt to better serve our customers (real and prospective) and partners, but keep this reminder about how ‘security cannot only be words’ in mind as you explore wildly hyped technology options with enthusiasts who promote them.

REFERENCES

Administrative Proceeding File No. 2016-CFPB-0007
In the Matter of: Dwolla, Inc. Consent Order

Dwolla: https://www.dwolla.com/

“We are Never Done.” http://blog.dwolla.com/we-are-never-done/

“Dwolla fined $100,000 for misleading data security claims.”
Federal agency orders D.M.-based financial technology firm to bolster security
Matthew Patane, The Des Moines Register, page 11A. 3/3/2016 (from the physical paper copy)

“CFPB Fines Fintech Firm Dwolla Over Data-Security Practices — Online-payment company agrees to improve how it protects customer data.”

What Can We Learn From Russian Attacks Against Ukrainian Power Companies?

February 26, 2016

The U.S. Dept. of Homeland Security (DHS) released a report about the December 23, 2015, Ukrainian power company outages caused by cyber-attacks.

Why should you care? These were targeted, effective, remote attacks against infrastructure operations to cause outages in subsidiary systems, as well as to demonstrate power.

As Financial Services consolidate their digital operations into ever-larger data centers — owned or third party — and migrate software and data to third party ‘cloud’ services — still more data center concentration — the risks associated with attacks against infrastructure are growing. Data centers are highly automated webs of complex power, heat management, monitoring, data communications, and access control infrastructure. Because of commercial data center consolidation, remote access to infrastructure systems is a given. If Financial Services enterprises’ infrastructures were the target of talented cyber-attack conceptually analogous to those against Ukrainian power company infrastructures, there would be serious negative consequences.

During those Ukrainian cyber-attacks, remote hostile actors used either existing remote administration tools at the operating system level or remote industrial control system (ICS) client software via virtual private network (VPN) connections to operate electric power flow controls. The hostile actors appeared to use a number of legitimate credentials during the cyber-attack to facilitate remote access.
These actors also wiped some systems by executing the KillDisk malware to render systems inoperable as they finished their attack.
They also corrupted firmware supporting Serial-to-Ethernet devices at substations.
Finally, they scheduled disconnects for server Uninterruptable Power Supplies (UPS) via the UPS remote management interface in an attempt to interfere with expected restoration efforts.
The targeted power companies also reported that they had been infected with BlackEnergy malware — reportedly delivered via spear phishing emails with malicious Microsoft Office attachments. Researchers suspect that BlackEnergy may have been used as an initial access vector to acquire legitimate credentials

Exhibit continuous due diligence in your selection and management over your data communications infrastructure & data centers. Protect them against all channels of unauthorized access. The threat of remote catastrophe or simply serious, serious outage is real.

REFERENCES:
Alert (IR-ALERT-H-16-056-01)
Cyber-Attack Against Ukrainian Critical Infrastructure
Original release date: February 25, 2016
https://ics-cert.us-cert.gov/alerts/IR-ALERT-H-16-056-01

Hackers did indeed cause Ukrainian power outage, US report concludes
DHS officials say well-coordinated hack cut power to 225,000 people.
by Dan Goodin – Feb 26, 2016 1:14pm CST
http://arstechnica.com/security/2016/02/hackers-did-indeed-cause-ukrainian-power-outage-us-report-concludes/


Complex Problems Remain

October 4, 2015

All of us involved in global financial services continue to be confronted with an expanding universe of “cloud” and “mobile” and “agile” options. Too many marketers for too many of these vendors seem to exercise increasingly predatory behaviors. A key result seems to be an escalation of risk management complexity…

In that context, I have been working on some complex issues…
Hofstadter’s Law (1979) still applies.

Hofstadter’s Law states that “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

REFERENCES:
Hofstadter’s Law: https://en.wikipedia.org/wiki/Hofstadter%27s_law


%d bloggers like this: