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