#AmericanCSM #Risk  #Assessment

When it comes to risk assessments, there isn’t a one size fits all kind of questionnaire template. You need to figure out what is important to your organization, your organization’s approach to governance, and the organization’s risk tolerance. There are lots of guides and thousands of canned questions to choose from, but it really depends on having the knowledge to ask the right questions about your specific organization.

• First, you need to identify what information your business manages. As they say, you can’t protect something you don’t know exists. List as many of these assets as you can. Create a table because you will fill in information, as seen below, about each asset.
• Second, you must figure out what the asset is worth. You can either use a dollar value or high/medium/low scoring system. Play the ‘what if’ game: What would happen if this asset was hacked? What would happen if this asset was stolen? What would happen if this asset wasn’t available for 24/48/72 hours?
• Third, create some attributes about the asset. Who owns it? Does it rely on a third-party? Where is it physically located? How quickly can I actually access it? Type of information (PII, PCI, PHI)? How quickly will I know if it is gone?
• Next, think about the impact that asset has on your business. Again, either dollar value or a high/medium/low scoring system.
• Now, understand the likelihood of specific threats and vulnerabilities. Using something like the National Vulnerability Database (NVD), US-CERT, or InfraGard you can get a list of common threats. This will help you prioritize the areas of focus.

With all this information you should get a great picture of where to concentrate your efforts. After this exercise you’ll know what you want to protect and whether or not it is protected to the appropriate value that it is worth.

A full risk assessment should be done on the assets which you determined are high risk, high value and have a high impact on your business. So, start simple and with something everyone can agree on. Start with determining your critical assets, what are your company’s crown jewels? The things that must be protected above all else. It should be easier to design a set of questions that will help you determine if these assets are well protected or not.

For small to midsized businesses, the CIS Top 20 Critical Controls is a good place to start, in order to define a set of standard security controls. Also, NIST has a great document Small Business Information Security: The Fundamentals to review.

There are also some simple things you can do today, even before you do the risk assessment:

• Always encrypt sensitive information both in transit and in storage
• Understand your data retention policy – if you don’t have the data, it can’t be compromised
• Limit access to information – the fewer people that can access it the better
• Create a good password policy – and enforce it!
• Patch your systems – as often as possible or at least know why they are not patched
• Ensure good boundary protection – including wireless access points and BYOD
• Train your employees on good security hygiene

Need help realizing the benefits of a risk assessment or need to turn your analysis into a Security and/or Privacy Strategy, please contact us at American Cyber Security Management today.

*American Cyber Security Management (AmericanCSM.com) is focused on reducing your risk of data misuse. We do this through our Security, Privacy and DevOps offerings, delivered by seasoned experts.

Cloud Security Alliance (CSA), the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure computing environment, has released their take on the European General Data Protection Regulations (GDPR) which take effect May 2018. In addition to releasing the CSA Code of Conduct for GDPR Compliance they also have launched the CSA GDPR Resource Center designed to educate Cloud Security Providers (CSP) about the new regulations.

The “CSA Code of Conduct for GDPR Compliance” offers cloud customers a tool to evaluate the level of personal data protection offered by different CSPs and make informed decisions on how they will secure that data,” said Daniele Catteddu, Chief Technology Officer, CSA. “We are extremely proud of the work that went into this latest iteration.”

As most companies struggle to understand the requirements of GDPR, CSA is taking the holistic approach by adding it to their existing Privacy Level Agreement Working Group. The PLA Working Group is comprised of independent privacy and data protection subject matter experts, privacy officers, and representatives from data protection authorities. This gives CSA the advantage of adding GDPR to what they already know about other compliance standards.

Need help realizing the benefits of GDPR or converting your GDPR Project into a real Privacy Strategy, please contact us at American Cyber Security Management today.

*American Cyber Security Management (AmericanCSM.com) is focused on reducing your risk of data misuse. We do this through our Security, Privacy and DevOps offerings, delivered by seasoned experts. Our Privacy specialists can help you make sense of and comply with GDPR.

 

Who was breached today? This is the common question. Days are gone where we wonder if a business was breached or if our data was stolen from a public system. But what happens after May 25th, 2018 when GDPR is in full effect?

With the European Union’s (EU) enactment of the General Data Protection Regulation (GDPR), if breached systems contain European citizen information then specific steps and the timing of those steps are now mandated.

How many cases have we seen where U.S. companies are taking weeks, months, to even a year to disclose to their customers that their data has been inappropriately accessed, lost or stolen? In the recent case of Uber’s announcement, it took them more than one year to notify their customers of a massive data breach. Uber announced that over 57 million people were affected by their data breach and that 2.7 million were located in the UK.

How would this look under GDPR and the EU’s new watchful eye and powerful penalties? The EU wants to ensure communications of data breaches are accurate and timely. According to GDPR Article 33, any business who is suffering a breach of EU citizen information must notify the EU authorities within 72 hours. And the notice must contain, at a minimum; Nature of the breach, Name and contact details of the company’s Data Protection Officer (DPO), Description of the likely consequences, and a description of the corrective steps being taken. Secondarily, the business must also notify the EU citizens under Article 34 definitions. This article requires that notice is given “without undue delay” and the content of the breach notice to be a subset of the information sent to the EU authorities.

These few rules will change how many global U.S. companies handle breach notification and it will undoubtedly impact their processes for incident management. The good news is that we are seeing many companies implement GDPR in a holistic way whereby they are including all customer data, regardless of citizenship, in their data classification strategy when approaching GDPR. This means that these companies will treat all customer data the same way as they need to under GDPR, and not silo EU citizen information, which would require a duplication of many business processes. GDPR is also helping these larger multinational businesses understand the value and role of the DPO, the one responsible for the assurance of the new privacy controls.

The GDPR may be one of the largest privacy regulations the world has ever seen, but it may be just in time. In a world of constant data breaches, we all need to be more diligent and concerned of how companies collect and use our data, share that information with their third party suppliers, and keep us notified of the access to our information.

*American Cyber Security Management (AmericanCSM.com) is focused on reducing your risk of data misuse. We do this through our Security, Privacy and DevOps offerings, delivered by seasoned experts. Our Security offerings reduce your risk at the Infrastructure, Network, and Application levels.

Defining the Baseline for Application Developers’ Security Knowledge

The blog posts that I’ve published over the past few weeks have explored the security skills gap and the training, resources, and processes required to address application security. In today’s article, let’s take a swing at defining the knowledge and skills our development staff needs in order to produce secure application software.

Recently, I was working with an education client and as we worked through defining the scope of the security-augmented developer course, we kept going back to the question “What security knowledge does a developer need to know when they come to work for you to be able to write secure code?”. I had never before sat down and produced a discrete list and that’s what we’ll do today. Because the responsibility for application security is shared by the developers, DevOps, and their management, today we’ll primarily look at the developer role, but refer to the others as needed.

For the purpose of this article (and the past two), the scope of “Application Security” is focused solely on the source code and the dependencies that are referenced therein. The topics of identity & access; data; network; infrastructure; and logging, auditing, & analysis are outside of this article’s discussion.

Here are a few items that must be implemented to secure in-house developed software:

1. A well-defined Software Development Life Cycle (SDLC).
2. OWASP T10 Trained developers and DevOps engineers.
3. Developer’s integrated Development Environment (IDE) tools augmented with security plugins.
4. Quality code processes
5. Standardized Logging Practices.

Defining the Baseline

From the list above, let’s pull out the developer skills out of each.

Well-Defined Software Development Lifecycle (SDLC)

A SDLC includes a detailed plan for how to develop, alter, maintain, and deploy a software system. From a security perspective, a key objective is to ensure ONLY code that is required to meet the release’s requirements is added and deployed in a release. The necessary development knowledge that comes into play is knowledge of a SCM Branching / Merging Model / Workflow such as Gitflow.

A developer should know how to branch, commit, merge software into the organization’s SCM (e.g. git or subversion) so that features that are not part of a release get introduced into the release codebase. In an organization that uses GIT as it’s SCM, the use of GITFlow² should be well understood by the development team members.

OWASP T10 Trained developers and DevOps engineers

The Open Web Application Security Project (OWASP) Top 10¹ (T10) covers the ten most critical software application’s security risks. While developers should understand all of the T10, in a modern enterprise software development organization where there are usually also SecOpsIT, DevOps, & Ops staff some of the OWASP T10 items will be the responsibility of the other groups.

For example regarding A2:2017 Broken Authentication, rarely would most development teams be implementing an Authentication system, that function is much more likely to be purchased as a third-party software package and installed, configured, & administered by SecOpsIT and/or Ops staff. This said, a developer should still understand A2:2017 Broken Authentication risk so that they don’t inadvertently expose a flaw through incorrect usage of a authentication package that allows an attacker to compromise passwords, keys, or session tokens.

The T10 risks that application developers should be generally most heavily focused on are:

• A1:2017 Injection
• A3:2017 Sensitive Data Exposure
• A5:2017 Broken Access Control
• A6:2017 Security Misconfiguration
• A7:2017 Cross-Site Scripting (XSS)
• A8:2017 Insecure Deserialization
• A10:2017 Insufficient Logging & Monitoring

With the following focused on only if the application accepts XML (A4) or there is no DevOps team:

• A2:2017 Broken Authentication – As discussed above, a developer typically needs only know how to appropriately use an authentication package, unless they are developing one.
• A4:2017 XML External Entities (XXE) — The use of XML as a data representation has been decreasing for a number of years. However, it is still used quite widely in legacy code, especially in financial/medical/insurance domains. If XML as a data transport is used within your organization and allows external entity references, then this risk should be a focus. BTW, this vulnerability was one of those exploited by the Equifax attackers.
• A9:2017 Using Components with Known Vulnerabilities — This should be addressed by both the developer using tooling in their IDE and the DevOps team implementing checks in the CI builds. Pro versions of Build Artifact Repository systems (Nexus & Artifactory) offer CVE checking on requested downloads and the ability to warn developers of issues during development.

Developers might consider using a security library such as OWASP’s Enterprise Security API ² to secure their applications using the library’s validation, encoding/decoding, and other security features to mitigate security issues.

Developers (+D), security testers (+T), application managers (+A), and organization’s (+O) security managers should read their perspective appendixes at the end of the T10 document for excellent role-specific information.

Integrated Development Environment (IDE) Security Tooling

Virtually all software developers use an IDE to write their code. These tools such as Eclipse (OSS) and Intellij IDEA (Lic) can be expanded via plugins. The developer should know how to install and use the appropriate plugins for their IDE of choice.

The Find Security Bugs (find-sec-bugs) plugin⁴ provides security audits of Java web applications and Android applications. (Also works with Groovy and Scala projects) for the Eclipse and IntelliJ platforms and is very well supported.

Note: the FindBugs parent project is dead, SpotBugs⁵ is its successor. Find Security Bugs has been updated to work with SpotBugs. See the migration document.

Quality & Security code processes

Writing quality code is the first step to creating secure code. Code reviews including both manual and automated are critical to ensuring the quality and security of your code. Likewise, unit and integration testing ensures that your code performs and provides the required functionality and continues doing so over time.

Reviews

For manual code reviews to be meaningful, they should cover both the style (coding convention) and the content of the code. The style is important because if differing styles are used across a codebase, then it will make maintenance and bug fixes more difficult. The content should be reviewed for efficiency, flexibility, security, and maintainability. OWASP provides a Java Security Practice ⁶ page to provide criteria to review the code. A developer should be able to describe the coding conventions and detect OWASP T10 risks in the code as well as any items described in the Java Security Practice.

 Automated reviews should be implemented in the CI jobs by the DevOps team. Both CVE dependency checks and static code reviews should be implemented. The same Find Security Bug project provides the Maven & Gradle dependencies to perform the static review. OWASP provides an OWASP Dependency-Check tool ⁷ to check the application’s dependencies for CVE issues.

Testing

Unit and integration testing of functionality are a staple of quality software development environments. An application’s security should also be unit and integration tested. A developer should be able to test their code with cross-site scripting, injection, and other OWASP T10 tests.

Standardized Logging Practices

Application logging is so crucial to detecting security incidents, monitoring policy violations, and providing additional application-specific data for incident investigation. The OWASP Logging Cheat Sheet ⁸ provides an excellent guide for application logging . A developer should be able to to enumerate:

• Event data sources
• Which events to log
• Event attributes
• Data to exclude

Summary

In order to build quality and secure software, developers should:

• Know their roles within an SDLC and specifically understand the SCM workflow used by the organization (e.g. GitFlow).
• Understand in depth the OWASP T10, these are the ten most critical security risks. However the T10 is only a beginning, developers must establish and use repeatable security processes and standard security controls.
• Understand the importance to integrate security tools such as SpotBugs/FindSecBugs into their IDEs.
• Be able to lead and/or participate in code reviews, incorporating security concerns into their reviews.
• Be able to develop security context unit and integration tests
• Be able to enumerate the logging:
  • Event data sources
  • Which events to log
  • Event attributes
  • Data to exclude

References

1. OWASP T10 Project: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
2. OWASP Enterprise Security API: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
3. Gitflow Workflow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
4. Find Security Bugs: https://github.com/find-sec-bugs
5. Spot Bugs: https://spotbugs.github.io/
6. Java Security Practice: https://www.owasp.org/index.php/Java_leading_security_practice
7. OWASP Dependency Check: https://www.owasp.org/index.php/OWASP_Dependency_Check
8. OWASP Logging Cheat Sheet: https://www.owasp.org/index.php/Logging_Cheat_Sheet

*American Cyber Security Management (AmericanCSM.com) is focused on reducing your risk of data misuse. We do this through our Security, Privacy and DevOps offerings, delivered by seasoned experts. We can ensure your Agile delivery processes are secured and efficient, while maximizing your investments.

Introduction

When we discuss application security, we focus on the application itself, not the networks or infrastructure that it will be operating within, just the products of the development team, comprised of the development manager, developers, DevOps engineers, and testers. The code that the developers write is but a slowly diminishing piece of the puzzle, increasingly developers are composing applications from a variety of generated code, frameworks, and libraries; any of which may be vectors for attack. How do we go about addressing the security of our developed applications?

OWASP to the rescue

You may be asking:

• How do we identify the application vulnerabilities?
• What risks do they pose?
• Where are they found in our code and how do we identify them?
• How do we prevent them?

Fortunately, we have the Organization for Web Application Security Project (OWASP), a 501(c)(3) worldwide not-for-profit charitable organization is focused on improving the security of software. They document the OWASP Top 10 Most Critical Web Application Security Risks which represents a broad consensus about the most critical security risks to web applications. Their project members include a variety of security experts from around the world who have shared their expertise to produce the documented list. 1 OWASP reviews and revises its Top Ten (T10) list every four years, with the most up-to-date version at the time of this writing being the 2017 RC2 2 (i.e. release candidate 2). The T10 list categorizes, ranks, and provides information for about the vulnerabilities, including how to detect and prevent them.

OWASP provides a broad range of resources for addressing all aspects of application security, many of which are referenced in the appendix of the T10 document. Of particular interest to me is the OWASP Testing Guide 3. While many of today’s software developers are familiar with Test Driven Development for functionality, the thought of adding tests to provide coverage for SECURITY vulnerabilities may seem foreign. Developers and DevOps engineers must learn the OWASP T10 and understand the tools they need to address validation, encoding/decoding, testing, and other techniques for addressing the vulnerabilities.

Steps to secure your application software

Creating secured application code requires:

• A defined Software Development Life Cycle (SDLC) — it is crucial that you know what changes are being introduced into your applications, that they are reviewed, and scanned for security vulnerabilities; these tasks must be part of the development culture and explicitly part of your SDLC.
• Trained developers and engineers — Assess your development team’s software security skills and make sure that they have periodic security training. The threats are changing all of the time, your teams much change with them. OWASP is a great starting point.
• Developer’s integrated Development Environment (IDE) tools augmented with security plugins — The earlier in the development process that security vulnerabilities can be detected, the less it costs to remediate those errors. The development teams should be using static code analysis plugins that can detect OWASP T10 vulnerabilities as they are entered into an Integrated Development Environment (IDE).
• Quality code processes including a security context (code reviews, both manual & automated static code analysis) — The best way to find issues of all types, but especially security is to go directly to the source code. In fact, there are some vulnerabilities that will be missed by automated scans.
• Standardize Logging Practices — Developers should have a guide to adding the needed logging statements to code to assist in the detection of attempts or breaches and providing the required information.
• Expand application testing to include security coverage — Just as your developers write tests for functionality, they should also be expected and assessed for developing security tests. Code reviews should include ensuring that both functionality and security tests are sufficient and accurate.
• Continuous Integration (CI) tasks static code analysis and dependency CVE analysis — CI servers’ build tasks should be configured to both perform static security code analysis (e.g.findsecbugs) and perform CVE analysis (e.g. OWASP Dependency-Check 4 ) on the dependencies of the software. If these controls had been in place, Equifax would have been alerted to the root cause issue that leads to their breach. If vulnerabilities are detected, the build should be failed. The development team management should be able to understand the generated report data.
• Development team managers trained to understand the need and purpose of the security & SLDC controls and who have the support from their management to ensure that they are utilized.

References

1. OWASP Top Ten Project: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
2. OWASP Top 10 2017 RC2 – PDF: https://www.owasp.org/images/b/b0/OWASP_Top_10_2017_RC2_Final.pdf
3. OWASP Testing Guide Introduction: https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_
4. OWASP Dependency Check: https://www.owasp.org/index.php/OWASP_Dependency_Check

*American Cyber Security Management (AmericanCSM.com) is focused on reducing your risk of data misuse. We do this through our Security, Privacy and DevOps offerings, delivered by seasoned experts. We can ensure your Agile delivery processes are secured and efficient, while maximizing your investments.