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.


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.


Getting through that Compliance-Only Mindset

December 1, 2016

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.
http://www.ncsl.org/research/telecommunications-and-information-technology/security-breach-notification-laws.aspx

A running list of U.S. security breach-related legislation by year (2010 to present):

http://www.ncsl.org/research/telecommunications-and-information-technology/overview-security-breaches.aspx

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.
http://www.ncsl.org/research/telecommunications-and-information-technology/data-disposal-laws.aspx

List of U.S. Identity Theft Laws:

http://www.ncsl.org/research/financial-services-and-commerce/identity-theft-state-statutes.aspx
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:

http://www.ncsl.org/research/telecommunications-and-information-technology/cybersecurity-legislation-2016.aspx
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.

Same for 2015:
http://www.ncsl.org/research/telecommunications-and-information-technology/cybersecurity-legislation-2015.aspx

List of U.S. Computer Crime Statutes:

http://www.ncsl.org/research/telecommunications-and-information-technology/computer-hacking-and-unauthorized-access-laws.aspx
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:

http://www.ncsl.org/research/telecommunications-and-information-technology/state-phishing-laws.aspx
Through 1/9/2015.
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

http://www.ncsl.org/research/telecommunications-and-information-technology/state-spyware-laws.aspx
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.

Also:

Perkins Coie’s list of U.S. State Security Breach Notification Laws:

https://www.perkinscoie.com/en/news-insights/security-breach-notification-chart.html
(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.
https://www.dlapiperdataprotection.com/index.html#handbook/world-map-section
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:
https://www.dlapiperdataprotection.com/system/modules/za.co.heliosdesign.dla.lotw/functions/export.pdf?country=all
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.
http://www.itgovernanceusa.com/data-breach-notification-laws.aspx


This Just In: Water is Wet

November 10, 2016

I received a link this morning from a colleague about office space.  it was an entertaining and interesting diversion from the all too often inward-focused grind.

It reminded me that other fields, not only Information Security, seem to suffer from unproductive, unbusiness-like amounts of “hope as a strategy”, unearned & misplaced trust, faith-based belief systems, flimflam, misdirection, puff, raw emotion, as well as lots of hype & hype-sters.

The article linked below is a quick read about alternative ways to frame some of the current blather about how reshaping the office environment necessarily leads to business benefits.  If you find this topic of interest, it appears to be the focus of some adult attention & analysis — see your favorite search engine for more.  If you are really interested, search on “herd behavior” and on “cognitive traps.”  There are many paths to broadly shared beliefs in “solutions” that are both unsupported by and contradicted by what often seem to be easy to grasp facts.  We still face lavish challenges.

REFERENCE:
“The Myths behind Brainstorming, Open Office Plans, and Collaboration.”
By Linda Hayes – November 3, 2016
https://www.techwell.com/techwell-insights/2016/11/myths-behind-brainstorming-open-office-plans-and-collaboration


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

 


%d bloggers like this: