Published 'Hacking Portugal' Book

I just published the 'Hacking Portugal' book which is based on the "Hacking Portugal and making it a global player in Software development"  presentation I delivered at BSidesLisbon in November 2016.

You can get it from amazon

or at  https://leanpub.com/hacking-portugal/

Presentation: Veracode Automation CLI (using Jenkins for SDL integration)

Here is a presentation about an secure CI workflow that I'm working on.

The key parts are the Veracode CLI developed (see veracode-api) and the couple Jenkins projects which use the Veracode engine in a 'concurrent scanner' model.

Let me know what you think of it:

Presentation "Hacking Portugal and making it a global player in Software development"

UPDATE: See Hacking Portugal book for an expanded and updated version of these ideas (available from Amazon)

---

Here is the presentation I delivered today at BSidesLisbon

There is an extended version of these ideas on this GitHub repo which you can read online at: https://diniscruz.github.io/keynote-bsideslisbon/

Description: As technology and software becomes more and more important to Portuguese society it is time to take it seriously and really become a player in that world. Application Security can act as an enabler, due to its focus on how code/apps actually work, and its enormous drive on secure-coding, testing, dev-ops and quality. The same way that Portuguese navigators once looked at the unknown sea and conquered it, our new digital navigators must do the same with code. This presentation will provide a number of paths for making Portugal a place where programming, TDD, Open Source, learning how to code, hacking (aka bug bounty style) and DevOps are first class citizens.

Relationship with existing standards

It is important have a good understanding of how a company's Risk profile maps to existing security standards alike PCI DSS, HIPAA, and others.

Most companies will fail these standards when their existing 'real' RISKs are correctly identified and mapped. This explains the difference between being 'compliant' and being 'secure'.

Increasingly, external regulatory bodies and laws require some level of proof that companies are implementing security controls.

I don't know the security status of a website

Lack of data should affect decision-making about application security.

Recently, I looked at a very interesting company that provides VISA compatible debit-card for kids, which allows kids to get a card whose budget can be controlled online by their parents. There is even a way to invest in the company online via a crowdfunding scheme.

I looked at this company as a knowledgeable person, able to process security information and highly technical information about the application security of any web service. But I was not able to make any informed security decision about whether this service is safe for my kids. I couldn't understand the company's level of security because they don't have to publish it and, therefore, I don’t have access to that data.

Published "SecDevOps Risk Workflow" book (v0.65)

I just published version v0.65 of the SecDevOps Risk Workflow book.

You can get the book (for free) at https://leanpub.com/secdevops (when you become a reader you will get email alerts with every release)

The diff for this version (with v0.63) shows 115 commits, 59 changed files, 545 additions and 355 deletions.

Creating better briefs

Developers should use the JIRA workflow to get better briefs and project plans from management. Threat Models are also a key part of this strategy.

Developers seldom find the time to fulfil the non-functional requirements of their briefs. The JIRA workflow gives developers this time.

The JIRA workflow can help developers to solve many problems they have in their own development workflow (and SDL).

(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)

Cloud Security

One way in which cloud security differs from previous generations of security efforts, such as software security and website security, is that in the past, both software and website security were almost business disablers. The more features and the more security people added, the less attractive the product became. There are very few applications and websites that make the client need more security to do more business, which results in the best return on investment.

What’s interesting about cloud security is that it might be one of the occasions where security is a business requirement, because a lack of security would slow down the adoption rate and prevent people from moving into the cloud. Accordingly, people care about cloud security, and they invest in it.

Feedback loops are key

A common error occurs when the root cause of newly discovered issues or exploits receives insufficient energy and attention from the right people.

Initially, operational monitoring or incident response teams identify new incidents. They send the incidents are to the security department, and after some analysis the development teams receive them as tickets. The development teams receive no information about the original incident, and are therefore unable to frame the request in the right perspective. This can lead to suboptimal fixes with undesired side effects.

Understand Every Project's Risks

It is essential that every developer and manager know what risk game they are playing. To fully know the risks, you must learn the answers to the following questions:

• what is the worst-case scenario for the application?
• what are you defending, and from whom?
• what is your incident response plan?

Always take advantage of cases when you are not under attack, and you have some time to address these issues.

(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)

Using logs to detect risks exploitation

Are your logs and dashboards good enough to tell you what is going on? You should know when new and existing vulnerabilities are discovered or exploited. However, this is a difficult problem that requires serious resources and technology.

It is crucial that you can at least detect known risks without difficulty. Being able to detect known risks is one reason to create a suite of tests that can run against live servers. Not only will those tests confirm the status of those issues across the multiple environment, they will provide the NOC (Network Operations Centre) with case studies of what they should be detecting.

Capture knowledge when developers look at code

It is vital that when a developer is looking at code, he can create tickets for 'things noticed' without difficulty. For example, 'things noticed' include methods that need refactoring, complex logic, weird code, hard-to-visualize architecture, etc. If this knowledge is not captured, it will be lost.

The developer who notices an issue, and opens a ticket for the issue, will be unable to do anything about it at that moment in time, since he will already be focused on resolving another bug.

Describe Risks as Features rather than as Wishes

When opening a risk JIRA ticket, it is essential to describe the exact behavior of that issue as a feature, rather than describing what you would like to see happening (i.e. your wish list).

For example:

• instead of saying 'application should encode XYZ value', you should say 'XYZ value is not encoded'
• instead of saying 'application shouldn't be vulnerable to XSS or SQL injection', you should say 'application is vulnerable to SQL injection'. In this case, SQL Injection is a feature of the application, and while the application allows SQL Injection, the application is working as designed (whether that is intended or not is a different story).

When we describe vulnerabilities, we describe features, because vulnerability is a feature of an application.

The smaller the ticket scope the better

For bugs and tasks, the smaller the bug the better.

Having many small bugs and issues can be an advantage for the following reasons:

• easier to code
• easier to delegate (between developers)
• easier to outsource
• easier to test
• easier to roll back
• easier to merge into upstream or legacy branches
• easier to deploy

It is better to put them in a special JIRA project(s) which can be focused on quality or non-functional requirements.

Collaboration Technologies

The following technologies are crucial for Security Champions and JIRA workflows to work efficiently:

Conference for Security Champions

Every 6 to 12 months, it is a good idea to hold a conference exclusively dedicated to security champions, particularly for companies that have multiple locations, where its security champions don't meet regularly in person.

At the conference, external speakers should present on specific topics.

If there are already several external AppSec consulting companies under contract to the hosting company, the consultants involved in existing projects are perfect candidates to present to the conference. They can use their own examples and stories, and it is easier to present internal materials if all participants are signed-up to the same NDA (Non-Disclosure Agreement).

Create an Technology Advisory Board

One of the biggest challenges in Agile and DevOps environments is the adoption rate of new technologies.

To be as agile as possible, there is a tendency to adopt new technology whenever it appears to have an advantage. Common examples are cloud technology, analytic tools, continuous integration tools, container technology, web platforms and frameworks, and client-side frameworks.

Inaction is a risk

Lacking the time to perform 'root cause analysis', or not understanding what caused a problem, are valid risks in themselves.

It is key that these risk are accepted

This is what makes them 'real', and what will motivate the business owner to allocate resources in the future. Specially when a similar problem occur.



(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)

Risk accepting threat model

If you have trouble getting developer teams to create threat models, or to spend time on those threat models, then the solution is to make them accept the risk incurred from not having a threat model for the application.

The idea is not to be confrontational. Instead, stating that a feature has no threat model is a very pragmatic, focused, and objective statement.

The idea is that the developer team must accept that they don't have a threat model. The logic is to create a ticket that says there is no threat model, and the ticket will be closed when the threat model is created. Alternatively, if the developers and their management team don't want to spend the time creating a threat model, they must accept the risk of not having one.

This can be difficult to accept, but it's an important part of the exercise.



(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)

How to review Applications as a Security Champion

When you review applications as a security champion, you need to start by looking at the application from the point of view of an attacker. In the beginning, this is the best way to learn.

You should start thinking about data inputs, about everything that goes into the database, the application, all the entry points of the application. In short, think about everything an attacker could control, which could be anything from headers, to cookies, to sockets, to anything that enters the application.

Authorization is also a great way to look at the application. Just looking at how you handle data, and how you authorise things, is a great way to understand how the application works.


(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)