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


Make use of OWASP Mobile Top 10

February 14, 2017

OWASP “Mobile Security Project” team updated their Mobile Top 10 Vulnerability list this week. {in the process they broke some of their links, if you hit one, just use the 2015 content for now: https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad}

I was in a meeting yesterday with a group reviewing one facet of an evolving proposal for Office 365 as the primary collaboration and document storage infrastructure for some business operations.

Office 365 in global Financial Services? Yup. Technology pundits-for-sale, tech wannabes, and some who are still intoxicated by their mobile technology have been effective in their efforts to sell “cloud-first.” One outcome of some types of “cloud-enabled” operations is the introduction of mobile client platforms. Even though global Financial Services enterprises tend to hold many hundreds of billions or trillions of other people’s dollars, some sell (even unmanaged) mobile platforms as risk appropriate and within the risk tolerance of all relevant constituencies… My working assumption is that those gigantic piles of assets and the power that can result from them necessarily attract a certain amount of hostile attention. That attention requires that our software, infrastructure, and operations be resistant enough to attack to meet all relevant risk management obligations (contracts, laws, regulations, and more). This scenario seems like a mismatch — but I digress.

So, we were attempting to work through a risk review of Mobile Skype for Business integration. That raised a number of issues, one being the risks associated with the software itself. The mobile application ecosystem is composed of software that executes & stores information locally on mobile devices as well as software running on servers in any number of safe and wildly-unsafe environments. Under most circumstances the Internet is in between. By definition this describes a risk-rich environment.

All hostile parties on earth are also attached to the Internet. As a result, software connected to the Internet must be sufficiently resistant to attack (where “sufficient” is associated with a given business and technology context). Mobile applications are hosted on devices and within operating systems having a relatively short history. I believe that they have tended to prize features and “cool” over effective risk management for much of that history (and many would argue that they continue to do so). As a result, the mobile software ecosystem has a somewhat unique vulnerability profile compared to software hosted in other environments.

The OWASP “Mobile Security Project” team research resulted in the Top 10 mobile vulnerabilities list below. I think it is a useful tool to support those involved in thinking about writing or buying software for that ecosystem. You can use it in a variety of ways. Challenge your vendors to show you evidence (yes, real evidence) that they have dealt with each of these risks. You can do the same with your IT architects or anyone who plays the role of an architect for periods of time — then do it again with your developers and testers later. Business analysts, or those who act as one some of the time should also work through adding these as requirements as needed.  Another way to use this Mobile Top 10 resource is to help you identify and think through the attack surface of an existing or proposed mobile-enabled applications, infrastructure, and operations.

OK, I hope that provides enough context to make use of the resource below.

REFERENCES:

Mobile Top 10 2016-Top 10
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10

M1 – Improper Platform Usage
https://www.owasp.org/index.php/Mobile_Top_Ten_2016-M1-Improper_Platform_Usage
This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk.

M2 – Insecure Data Storage
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M2-Insecure_Data_Storage  This new category is a combination of M2 + M4 from Mobile Top Ten 2014. This covers insecure data storage and unintended data leakage.

M3 – Insecure Communication
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M3-Insecure_Communication This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc.

M4 – Insecure Authentication
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M4-Insecure_Authentication This category captures notions of authenticating the end user or bad session management. This can include:
Failing to identify the user at all when that should be required
Failure to maintain the user’s identity when it is required
Weaknesses in session management

M5 – Insufficient Cryptography
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M5-Insufficient_Cryptography The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn’t done correctly.

M6 – Insecure Authorization
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M6-Insecure_Authorization This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrolment, user identification, etc.).

If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure not an authorization failure.

M7 – Client Code Quality
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M7-Poor_Code_Quality
This was the “Security Decisions Via Untrusted Inputs”, one of our lesser-used categories. This would be the catch-all for code-level implementation problems in the mobile client. That’s distinct from server-side coding mistakes. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that’s running on the mobile device.

M8 – Code Tampering
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M8-Code_Tampering
This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.

Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.

M9 – Reverse Engineering
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M9-Reverse_Engineering
This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back end servers, cryptographic constants and ciphers, and intellectual property.

M10 – Extraneous Functionality
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M10-Extraneous_Functionality Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing.


Another Demonstration of How Mobile Phones & their Supporting Networks are Vulnerable to Abuse

April 17, 2016

Some continue to hype “bring your own device” (sometimes just BYOD) as near-term technology and business goal for global Financial Services enterprises.  At its most shrill, the argument hammers on the idea like ‘we all have a smart phone and it has become the center of our lives…‘  In this industry we are all responsible for protecting trillions of dollars of other people’s money as well as digital information about customers (individuals & companies), partners, and deals, all of which must remain highly secure, or the foundation of our business erodes.  That responsibility is wildly out of alignment with most BYOD realities.  In that context, this blog entry is an offering to help risk management teams educate their Financial Services organizations about some of the risks associated with using mobile phones for work activities.

Here is some content that may be useful in your security awareness campaign…

Financial Services executives “private” communications could be of high value to cyber criminals. So too could be your Finance staff, Help Desk, Reporting Admin, Database Admin, System Admin, and Network Admin communications. There are a lot of high value avenues into Financial Services organizations.

Under the title “Hacking Your Phone,” the 60-Minutes team have security professionals demonstrate the following in a 13 minute video:

  • Any attacker needs just their target’s phone number, to track the whereabouts, the text traffic, and the details of phone conversations initiated or received by their prey. Turning off your “location status” or other GPS technology does not inhibit this attack. It depends upon features in the SS7 (Signalling System #7) network that have been overly permissive and vulnerable to abuse for decades. These SS7 vulnerabilities appear to remain after all this time because of nation-state pressures to support “lawful interception.”
    They demonstrate their assertion in an experiment with U.S. Representative Ted Lieu, a congressman from California.
  • Attackers can own all or some of your phone when you attach to a hostile WiFi. Never trust “public” or “convenience” (for example “hotel”) WiFi. Attackers present look-alike WiFi (sometimes called “spoofing”) and then use human’s weakness for “trustworthy” names to suck targets in.
    They demonstrate this approach by stealing a target’s mobile phone number, account ID, and all the credit cards associated with– with that account, along with their email.
  • Attackers use social engineering to get their software installed on targeted devices. One outcome is that they can also monitor all your activity via your mobile phone’s camera and microphone — without any indication from the mobile device screen or LEDs, and the attacker’s software does not show up via any user interface even if you tried to find it.
    They demonstrate this approach with the 60 Minutes interviewer’s device.

Remember, not everyone employed throughout Financial Services enterprises understands the risks associated with performing business activities via mobile devices.  Use materials like this video to augment your risk awareness program.

REFERENCES:
“Hacking Your Phone.” aired on April 17, 2016
http://www.cbsnews.com/news/60-minutes-hacking-your-phone/

SS7, Signalling System #7 https://en.wikipedia.org/wiki/Signalling_System_No._7

Lawful interception.” https://en.wikipedia.org/wiki/Lawful_interception

 

 


Targeted Phishing Still Works – Resistance is Critical

February 29, 2016
As many have been reporting today, one of Snapchat’s employees was recently targeted by online criminals who convinced them that they were the company’s CEO.
Then what?
In response to the targeted phish, the employee emailed a copy of some company payroll details to what they hoped was their CEO.  As a result, a number of Snapchat’s workers have had their identities compromised [not Snapchat’s millions of users].
Still, and too often, social engineering works…
Members of any Financial Services workforce need to resist this force all day, every day.
In this 4 minute video, Graham Cluley outlines how this can happen and how employees might reconsider breaking the rules.
His final guidance can be summarized as: “It’s okay to say no.”
He is an entertaining presenter and his message is completely applicable to any Financial Services work environment.
Take a break for this 4 minute security reminder: https://www.youtube.com/watch?v=PpNDpnXXiOA
REFERENCE:
 Snapchat Apology:
http://snapchat-blog.com/post/140194434840/an-apology-to-our-employees
VIDEO: “Snapchat data breach shows that sometimes it’s good to say no to your CEO. — Do you mind just sending over the payroll database?”
By Graham Cluley, February 29, 2016
https://www.youtube.com/watch?v=PpNDpnXXiOA

Mac Boot Hacked via Thunderbolt Port

January 14, 2015

Too many of us still have to deal with members of our workforce who hold groundless beliefs about the freedom from risk they enjoy while using their Macs.

Trammell Hudson described his most recent project at the last Chaos Communication Congress in Germany. It is called Thunderstrike and it can infect any modern Mac boot ROM via the Thunderbolt port — ultimately giving the attacker control of the endpoint. This “evil maid” attack gives us all another reason for concern. Anyone with physical access to a worker’s Mac could use this technique (or one of its predecessors) as a foothold into your network, as well as gaining “direct” access into any operations to which that user has been permitted. Traveling executives seem like obvious targets, but virtually any member of the workforce is a candidate.

Mr. Hudson describes the impact of his attack as:

“There are neither hardware nor software cryptographic checks at boot time of firmware validity, so once the malicious code has been flashed to the ROM, it controls the system from the very first instruction. It could use SMM, virtualization and other techniques to hide from attempts to detect it.

Our proof of concept bootkit also replaces Apple’s public RSA key in the ROM and prevents software attempts to replace it that are not signed by the attacker’s private key. Since the boot ROM is independent of the operating system, reinstallation of OS X will not remove it. Nor does it depend on anything stored on the disk, so replacing the hard drive has no effect.”

At a minimum, this should be used as input for traveler’s security awareness training.

It should also be injected into risk analyses of all BYOD scenarios.

REFERENCES
“Thunderstrike.” By Trammell Hudson.
https://trmm.net/EFI

“De Mysteriis Dom Jobsivs: Mac EFI Rootkits.” By Snare (Blackhat 2012)
http://ho.ax/downloads/De_Mysteriis_Dom_Jobsivs_Black_Hat_Slides.pdf

“Apple’s Mac EFI found vulnerable to bootkit attack via rogue Thunderbolt devices.” By Sam Oliver, Dec 22, 2014
http://appleinsider.com/articles/14/12/22/apples-mac-efi-found-vulnerable-to-bootkit-attack-via-rogue-thunderbolt-devices

“Thunderstrike: The scary vulnerability in your Mac’s Thunderbolt port.” By Christina Warren, Jan 02, 2015
http://mashable.com/2015/01/02/thunderstrike-mac/

Macs vulnerable to virtually undetectable virus that “can’t be removed” By Adrian Kingsley-Hughes, Jan 12, 2015
http://www.zdnet.com/article/macs-vulnerable-to-virtually-undetectable-virus-that-cant-be-removed/


%d bloggers like this: