​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/


Bumper Sticker from RBS

February 19, 2017

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.

RESOURCES:

“Risk Based Security, NIST and University of Maryland Team Up To Tackle Security Effectiveness.”
https://www.riskbasedsecurity.com/2017/02/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/.


4 Agile Security Principles

August 30, 2016

Yesterday Citigal proposed a set of principles to complement the Agile Manifesto.  Authors of the Agile Manifesto emphasized:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Cigital offers four principles to help address inefficiencies that too often slow application security. They intent that these four principles will “guide and inspire us to build secure software in an agile way.”

  1. Rely on developers and testers more than security specialists.
  2. Secure while we work more than after we’re done.
  3. Implement features securely more than adding on security features.
  4. Mitigate risks more than fix bugs.

I assume that Citigal built their list in the Agile Manifesto model, as an expression of their valuing the items on the right — just not as much as they value the items on the left.  Not only do these principles align with and extend the original Agile Manifesto, it seems like they may also help information and software security organizations scale their efforts.  None of us has all the resources we need.  Sensitive use of the “Cigital four” listed above may help us build capacity…

These seem like an excellent resource for those leading secure software efforts as well as for architects, designers, product owners — anyone attempting to influence software quality while managing software induced risks to appropriate levels.

RESOURCES

Cigital: https://www.cigital.com/

The Agile Manifesto: http://agilemanifesto.org/

Cigital’s 4 Principals: https://www.cigital.com/resources/ebooks-and-whitepapers/agile-security-manifesto-principles/

There is no single “Agile” way: https://en.wikipedia.org/wiki/Agile_software_development#Agile_methods

 


Recognize the Fact of Android Endpoints

April 20, 2016

The BYO hypesters that I am exposed to tend to trend strongly toward all things Apple.

Earlier today, a ranking security leader saw a slide highlighting the history of iOS and OSx vulnerabilities and snapped something about the market speaking through Apple’s sales dominance… …as if Apple ‘owned’ our customer, prospect, and employee population.

This seems to happen a lot. I work for an overtly “global” financial services corporation. Leading technologists on staff promote Apple products as the solution to virtually any endpoint challenge (we currently do our business on tens of thousands of Windows endpoints running Windows applications…). The company that pays us is attempting to generate strategic expansion in Latin America and Asia…  We want and need to service people’s financial services needs where they are — meaning strong support for interactions via their mobile devices.  The mismatch is cringe-worthy.

How does this marketplace blind spot afflict so many people who otherwise are intelligent adults?  I really don’t know.  Maybe financial services professionals are becoming prisoners of their own cognitive traps?

MacRumors recently announced that “iOS and Android Capture Combined 98.4% Share of Smartphone Market.” The Apple portion of that global 2015 market share was 17.7% (down from 20.4% in 2014). Android-based mobile devices represented 80.7% of the 2015 market (up from 76.0% in 2015).

Year after year people around the world purchase more Android mobile devices than the competing Apple devices. In 2015 that amounted to more than 4.5 Android mobile devices purchased for every Apple iOS device sold.

Gartner (Feb 2016) reported:

Worldwide Smartphone Sales to End Users by OS in 4Q15 (in Thousands of Units)

           4Q15     4Q15 Market   4Q14      4Q14 Market
        Units Sold  Share %     Units Sold  Share %
Android 325,394     80.7        279,057     76.0
iOS      71,525     17.7         74,831     20.4
Windows   4,395      1.1         10,424      2.8
Blackberry  906      0.2          1,733      0.5
Others      887      0.2          1,286      0.4

 

Sure, the Android == ‘security hell’ meme has some good reasons for retaining its foothold in business culture. And sure, there are many more ‘ancient’ unpatched/underpatched Android devices compared to the iOS environment. There are attractive and repulsive characteristics of Android/iOS environments that we can argue about, but that avoids the fact that our employees, customers, and prospects buy and use more Android devices.  A lot more.  We will leave a lot of money on the table if we ignore that fact and build software & operations that are tightly-coupled with Apple mobile device products.

OK. I had to get that out of my system…

REFERENCES

“iOS and Android Capture Combined 98.4% Share of Smartphone Market.”
By Joe Rossignol, Feb. 18, 2016
http://www.macrumors.com/2016/02/18/ios-android-market-share-q4-15-gartner/

“iPhone lost market share to Android in every major market except one.”
Jim Edwards, Jan. 27, 2016
http://www.businessinsider.com/apple-ios-v-android-market-share-2016-1


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.”

Will Governments Increase Their Involvement in Incident Response?

January 10, 2015

Time (and others) reported that NSA Director Admiral Michael Rogers told the International Conference on Cyber Security (ICCS) at Fordham University in New York:
“Sony is important to me because the entire world is watching how we as a nation are going to respond to [the attack on Sony].” “If we don’t name names here, it will only encourage others to decide, ‘Well this must not be a red line for the United States.'”
The attacks against Sony had begun in September, he said, with a flurry of tightly focused phishing attacks against key individuals. This was then used to gain full access to the company’s servers and to steal data.
Rogers stated, “I remain very confident: this was North Korea.”

Some cyber security experts seem less sure that accurately described what happened.

Rogers also said that hacks against private companies may require economic sanctions.

How did terabytes of data get stolen from Sony’s private network? Did Sony invest enough in attack resistance, identification, & response? Should there be more objective criteria upon which to help frame decision-making on this topic?

Since November I have been hearing a lot of discussion about “Sony” and “The Sony Hack.”   Should we in Financial Services begin including NSA monitoring, forensic assistance, and consulting in our incident response planing?
How will the U.S. (along with other nations in this global business environment) decide which hacks against private companies deserve a governmental response, and which will not?  And what if your company has business in both the source and target countries of a given attack?  It seems like each of our organizations need to work through these issues before the day they become critically important — and a small herd of corporate officers on an incident response call are waiting for your direction.

What do you think?

REFERENCES:
“NSA Director on Sony Hack: ‘The Entire World is Watching’.”
http://time.com/3660757/nsa-michael-rogers-sony-hack/
By Sam Frizell, 01-08-2015

“FBI fingering Norks for Sony hack: The Truth – by the NSA’s spyboss.”
http://www.theregister.co.uk/2015/01/09/fbi_nsa_sony_pictures_north_korea/
By Iain Thomson, 01-09-2015

“Are We Asking the Right Questions in the Wake of the Sony Pictures Breach?”
http://www.wired.com/2015/01/right-questions-sony-pictures-breach/
By Paul Martini, 01-09-2015


%d bloggers like this: