Saturday, 3 December 2016

Please help to set the date for the next OWASP DevSecCon Summit. Great description of OWASP Summits

Hi, we are in the final stages of choosing the date for the next OWASP Summit and it would be great if you chipped in with your preference.

Please use the http://doodle.com/poll/e8d4p955rc8guuru doodle and join the other 44 participants.

The OWASP Summit is starting to shape up quite nicely with already a number of good workshops ideas in the works. Please check them out at https://github.com/OWASP/owasp-devseccon-summit/tree/master/Workshops and help to make them better:
  • what topic is missing?
  • who should be at those workshops?
  • what should the participants focus on?
  • what should the be objectives/outcomes?
If you have not been to an OWASP Summit before (i.e the 2008 and 2011 editions) please see below a great description of what they are (from an email sent by Abraham Kang on 6 Apr 2012).

Thanks for your help

Dinis, Seba & Francois

----------------------------------------

Although, I agree with Jim in spirit.  

I have to admit that I was able to get things accomplished at the 2011 Summit that would have taken longer had I not attended the Summit.

I was kind of Stuck on the DOM based XSS cheat sheet because there were just so many existing ways and new ways of exploiting DOM based XSS.  I was lost in trying to understand the exploiting instead of focusing on the Mitigating. 

The Summit gave me an opportunity to work with some of top guys  ( Jim Manico, Stefano Di Paola, Robert Hansen, Gareth Hazes,  Chris Schmidt,  Mario Heiderich, Eduardo Nava, Achim Hoffman, John Stevens, Arian Evans, Mike Samuel, Jeremy Long, Dinis Cruz, and others please forgive me if I forgot to mention you) in Web security to get their ideas and refine mine.  
I also was able to bring up issues that were affecting adoption by large enterprises of OWASP materials with Jeff Williams and others.

Finally, I was also able to meet the people interested in OWASP Web Development Guide (which I have been trying to reboot but having started a new job have failed to make much progress on) to discuss issues related to the guide and try to address them.

All of this would have been impossible to do without the summit.

I was also hoping to suggest that this year we try to bring other security members of the community that haven't traditionally participated (iSec Partners, Gotham Digital Science, etc.) in OWASP to the summit as I have great respect for those guys and think they could contribute greatly to the success of OWASP.  

The conference is viewed as being private but I thought it was open to anyone interested in contributing to OWASP.  I think people would be willing to pay to attend a conference where they could speak to other leaders in informal meetings on topics of interest and provide the additional benefit of OWASP deliverables.

We are a very disperse group, it helps to get people together to work things out, discuss and see the other people as human beings. I have to admit that the conference was also a lot of fun.  I got to laugh with people I would have never had the chance to before this.  Jokes don't seem to go over as well when they are made over email.  I got to hear stories of (Larry's or Chris's -- the last names have been omitted to protect the Guilty) midget experiences/encounters.  I got to know of other people skeleton's in their closets.  

This allowed all of us to bond in a way that couldn't happen without a conference like this.

Another benefit of these types of interactions is that everyone that attended last summit was involved with an OWASP project (which may be a good requirement).  I met Andras (my German brother) of WS-Attacks.org and although I haven't done a good job of it yet, I was hoping to reboot the OWASP Web Development Guide (I will send another email on that thread to explain my struggles) and see if I could use the content from WS-Attacks.org in the new guide (seeing as I did the translation revision for Andras) for the Web Services chapter.  If I didn't attend the Summit I wouldn't have met him and made this connection.

Yes there were a couple of things that could have been handled better related to the usurping of funds from individual Chapter's accounts and we probably could have spent less money on the incidentals but there is great value in the Summit.

OWASP Rocks!

Warmest Regards,
Abe

Sorry for being so long winded.

Thursday, 1 December 2016

Please review the 'Hacking Portugal' book available on Amazon (paperback and Kindle)

My 'Hacking Portugal' book is now available on Amazon and I would really appreciate your feedback and ideally an book review :)

Here is the Amazon page: https://www.amazon.co.uk/Hacking-Portugal-Making-Software-Development/dp/1540743632

You can download the PDF for free at LeanPub or from GitHub


This is my first book published at Amazon, and I have to admit that I'm quite proud of it :)

This book is based on the "Hacking Portugal and making it a global player in Software development" presentation I delivered at that BSidesLisbon and C-Days conferences (November 2016). All content is released under an Creative Commons licence at the Book_Hacking_Portugal GitHub repo

Friday, 18 November 2016

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:

Friday, 11 November 2016

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


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.

Monday, 7 November 2016

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.

Sunday, 6 November 2016

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.

Saturday, 5 November 2016

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.

Friday, 4 November 2016

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.

Thursday, 3 November 2016

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).

Wednesday, 2 November 2016

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)


Tuesday, 1 November 2016

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)


Monday, 31 October 2016

If you don't have a Security Champion, get a mug

If your developer team doesn't have an assigned security team champion, get one of these mugs.

That 'Security Expert' mug represents the fact that, without a securit champion, when a developer has an application security question, he might as well ask the dude on that mug for help.

I also like the fact that the mug reinforces the idea that for most developer teams, just having somebody assigned to application security is already a massive step forward!!

Basically, we have such a skill shortage in our industry for application security developers that 'if you have a heart-beat you qualify'

What it takes to be a Security Champion

To become a security champion, it is essential that you want to be one.

You need a mandate from the business that will give you at least half a day, if not one full day per week, to learn the role. The business should also provide the means to educate and train you and others who wish to become security champions. Increasing and spreading knowledge will increase awareness and control.

You need to be a programmer, and understand code, because your job is to start looking at your application and understand its security properties. You should also know 'the tools of the trade', and how to implement them, in the most efficient way. Lastly, you must be able to identify useful metrics and instruct on how to obtain them.


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


Sunday, 30 October 2016

If you have a heartbeat, you qualify!

It is important to understand that AppSec skills are not a key requirement to become a security champion. The essential quality is to want to become one.

I can make a good developer, who is interested and dedicated, into a good AppSec specialist in 6 months. If the developer is an expert in AppSec, then he should join the central AppSec team.


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