Innovation and Secure Software

November 15, 2017

​I sometimes get questions about the applicability of secure software standards and guidelines to work described as innovation or innovative.  Sometimes these interactions begin with an outright rejection of “legacy” risk management in the context of an emerging new “thing.”  I believe that under most circumstances, any conflict that begins here is voluntary and avoidable.  As global financial services organizations, our risk management obligations remain in force for mature & stable development projects as well as for innovation-oriented efforts.

In any discussion of innovation, I arrive with my own set of assumptions:

  • Innovation can occur at all levels of the human, business, operations, technology stack, and often requires concurrent change at multiple layers.
  • Innovation, in any context, does not invalidate our risk management obligations.
  • One of the most common and insidious innovation anti-patterns is constantly looking for the next hot tool that’s going to solve our/your problems.*

Software-centric innovation may generate new or help highlight existing gaps in your secure software standards/guidelines.

If there are gaps in your existing secure software guidance — so that the new “thing” seems to be out of phase and disconnected from that legacy, those gaps need to be closed.

Sometimes gaps like these appear because of changes in vocabulary.  This is generally an easy issue to deal with.  If all involved can agree on the trajectory of the innovative development, then you can begin with something as simple as a memo of understanding, with updates to secure software standards/guidelines to follow at a pace determined by the priority of that work (if there is a formal, fines & penalties regulatory compliance issue involved, it is a higher priority than if were only an exercise in keeping your documentation up-to-date).

Other times an organization is introducing a new business process, a new type of business, or a new technology that does not map well to the existing concepts and/or assumptions expressed in your secure software standards/guidance.  An example of this situation occurred as we all began to invest in native mobile apps.  At that time, mobile app ecosystems did not incorporate a lot of the common security mechanisms and capabilities that had been in place for server and desktop environments for a long time.  This type of change requires a mix of simple vocabulary and content change in corporate secure software standards/guidance.  Again, if those involved can agree on some fundamental assumptions about what the new software is doing and where it is executing, along with sharing an understanding of its external behaviors (passing data, resolving names, signaling, trusts, etc.), you can take a multi-step process to get secure software guidance synchronized with your business environment.  The first step being some sort of formal memo of understanding, followed by the research, collaboration, and writing required to get your secure software standards/guidelines and your business operations back into phase.

Is it possible that your enterprise could introduce something so alien and so disruptively new that there was just no connective tissue between that investment and your existing secure software guidance?  Sure.  What if financial services enterprises decided that they needed to begin building our own proprietary hardware (from the chips all the way up the stack to network I/O) to deal with the combination of gigantic data-sets, complex analyses, and extremely short timelines (throw in some ML & AI to add sex appeal).  Our current generation of secure software standards/guidelines would not likely be well aligned with the risk management challenges presented by microchip architecture, design, implementation and the likely tightly-coupled low level software development that would be required to use them.  I would not be surprised if much of what we have currently published in our organizations would be virtually unrelatable to what would be needed to address the scenario above.  I think that the only businesslike path to dealing with that secure software challenge would be to acquire highly-specialized, experienced human resource to guide us through that kind of dis-contiguous evolution.  That would be a material challenge, but one that our business will not often face.

Given the current state of our secure software training and guidance resources, it seems like most of us in global Financial Services enterprises should expect to find that most ​innovation efforts are aligned-enough with the existing secure software standards/guidelines, or (less frequently) only somewhat out of sync because of differences in vocabulary, or misaligned underlying assumptions or concepts.  Those are expected as part of our evolving software-driven businesses and the evolution of hostile forces that our businesses are exposed to.

So, innovate!  Any of our success in the global financial services marketplace is not guaranteed.  And, dive into working through decision-making about your architecture, design, and implementation risk management obligations.  And finally, use the existing technical and human resources available to you to deal with any new risk management challenges along the way.

* Rough quote from: “Practical Monitoring: Book Review and Q&A with Mike Julian.” By Daniel Bryant, Nov 07, 2017. https://www.infoq.com/articles/practical-monitoring-mike-julian.

Advertisements

Low Profile Office 365 Breach Reported

August 18, 2017

A couple years ago I wrote:

“I am told by many in my industry (and some vendors) that ‘if we put it in the cloud it will work better, cheaper, be safer, and always be available.’ Under most general financial services use cases (as opposed to niche functionality) that statement seems without foundation.”

Although many individuals have become more sophisticated in the ways they pitch ‘the cloud’ I still hear versions of this story on a fairly regular basis…

Today I learned about a recent Office 365 service outage that reminded me that issues concerning our use of ‘cloud’ technology and the commitments we in the Global Financial Services business make to our customers, prospects, marketers, investors, and regulators seem to remain very much unresolved.

What happened?

According to Microsoft, sometime before 11:30 PM (UTC) on August 3rd 2017, the company introduced an update to the Activity Reports service in the Office 365 admin center which resulted in customers usage reports of one tenant being displayed in another tenant’s administrative portal.

Some customer o365 administrators noticed that the reported email and SharePoint usage for their tenants had spiked. When they investigated, the o365 AdminPortal (https://portal.office.com/adminportal/) displayed activity for users from one or more AzureAD domains outside their tenant. In the most general terms, this was a breach. The breach displayed names and email addresses of those users along with some amount of service traffic detail, for example, user named X (having email address userNameX@domainY.com) sent 193 and received 467 messages, as well as uploaded 9 documents to SharePoint, and read 45 documents in the previous week.

Some subset of those 0365 customers reported the breach to Microsoft.

Microsoft reported that at they disabled the Activity Reports services at 11:40 PM UTC the same day, and that they had a fix in place by 3:35 AM UTC.

Why should I care?

As Global Financial Services Enterprises we make a lot of promises (in varying degrees of formality) to protect the assets for which we are responsible and we promote our ethical business practices. For any one or our companies, our risk profile is rapidly evolving in concert with expanded use of a range of cloud services. Those risks appear in many forms. All of us involved in Global Financial Services need our security story-telling to evolve in alignment with the specific risks we are taking when we choose to operate one or another portion of our operations in ‘the cloud.’ In addition, our processes for detecting and reporting candidate “breaches” also need to evolve in alignment with our use of all things cloud.

In this specific situation it is possible that each of our companies could have violated our commitments to comply with the European GDPR (General Data Protection Regulations: http://www.eugdpr.org/), had it happened in August 2018 rather than August 2017. We all have formal processes to report and assess potential breaches. Because of the highly-restricted access to Office 365 and Azure service outage details, is seems easy to believe that many of our existing breach detection and reporting processes are no longer fully functional.

Like all cloud stuff, o365 and Azure are architected, designed, coded, installed, hosted, maintained, and monitored by humans (as is their underlying infrastructure of many and varied types).
Humans make mistakes, they misunderstand, they miscommunicate, they obfuscate, they get distracted, they get tired, they get angry, they ‘need’ more money, they feel abused, they are overconfident, they believe their own faith-based assumptions, they fall in love with their own decisions & outputs, they make exceptions for their employer, they market their services using language disconnected from raw service-delivery facts, and more. That is not the whole human story, but this list attempts to poke at just some human characteristics that can negatively impact systems marketed as ‘cloud’ on which all of us perform one or another facet of our business operations.

I recommend factoring this human element into your thinking about the value proposition presented by any given ‘cloud’ opportunity. All of us will need to ensure that all of our security and compliance mandated services incorporate the spectrum of risks that come with those opportunities. If we let that risk management and compliance activity lapse for too long, it could put any or all of our brands in peril.

REFERENCES:
“Data Breach as Office 365 Admin Center Displays Usage Data from Other Tenants.”
By Tony Redmond, August 4, 2017
https://www.petri.com/data-breach-office-365-admin-center

European GDPR (General Data Protection Regulations)
http://www.eugdpr.org/


Pirated Software and Network Segmentation

July 17, 2017

Global financial services enterprises face a complex web of risk management challenges.
Sometimes finding the right grain for security controls can be a difficult problem.
This can be especially problematic when there is a tendency to attribute specific risks to cultures or nations.

A couple months ago I read a short article on how wannacry ransomware impacted organizations in China. Recently, while responding to a question about data communications connectivity and segmenting enterprise networks, I used some of the factoids in this article. While some propose material “savings” and “agility” enabled by uninhibited workforce communications and sharing, the global financial services marketplace imposes the need for rational/rationalized risk management and some level of due diligence evidence. Paul Mozur provides a brief vignette about some of the risks associated with what seems like China’s dependence on pirated software. Mr. Mozur argues that unlicensed Windows software is not being patched, so the vulnerability ecosystem in China is much richer for attackers than is found in societies where software piracy is less pronounced. Because of the scale of the issue, this seems like it is a valid nation-specific risk — one that might add some context to some individual’s urges to enforce China-specific data communications controls.

Again, there is no perfect approach to identifying security controls at the right grain. Story-telling about risks works best with real and relevant fact-sets. This little article may help flesh out one facet of the risks associated with more-open, rather than more segmented data communications networks.

REFERENCES:
“China, Addicted to Bootleg Software, Reels From Ransomware Attack.”
https://mobile.nytimes.com/2017/05/15/business/china-ransomware-wannacry-hacking.html


Insecure software is the root cause…

May 17, 2017

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.

https://blog.securitycompass.com/wannacry-and-the-elephant-in-the-room-c9b24cfee2bd


​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


Do Not Use On-Line Services to Encode or Encrypt Secrets

March 17, 2017

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:

powershell "[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes(\"mySecret\"))"

or

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.


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/


%d bloggers like this: