(My) BruCON 2018 Notes

Here are my quick notes from the BruCON 2018 conference. All the slides of the conference can be found here.

$SignaturesAreDead = “Long Live RESILIENT Signatures” wide ascii nocase (by Daniel Matthew)

Background

Signatures and indicators: what is a good signature ? A good signature depends of the context but the main properties are:

  • More resilient than rigid (resist evasion and normal changes).
  • More methodology-based than specific (capture methods or techniques).
  • More proactive than reactive (identifies new technologies )

Process

  • Define detection
    • what. where, when to find.
  • Assemble a sample set
    • collected sample set.
    • generated sample set.
    • try to enumerate the entire problem set.
  • Test existing detection/s
    • Test existing detection capabilities for any free wins.
    • Adjust priorities of existing applicable existing detections.
  • Generate data
    • logs.
    • binary metadata.
  • Write detection
    • start broad and tune after.
  • Test and tune

Process Walk-through for binaries

It applies the previous process to binaries.Malware binaries changes very often. In this case can’t rely on anti-viruses.

Process Walk-through for regsvr32.exe

It applies the previous process to the regsvr32.exe. It shows that is rather difficult to detect the regsvr32 arguments or process name
because there are multiple possibilities for the parameters for ex: /s or -s /u or -s or /us or -us.

Approaches that payed off to detect the execution of regsvr32.:

  • Handle obfuscation separately.
  • Handle renamed .exe/.dll separately

Takeaways

  • Know what you are detecting today and HOW you are detecting it.
  • Capture result of hunts as new detections.

All Your Cloud Are Belong To Us – Hunting Compromise in Azure (by Nate Warfield)

Traditional network (old days) Cloud Network
server restriction was restricted every vm exposed to internet
many layers of ACLs + segmentation VM’s deployed with predefined firewall
dedicated deployment teams anyone with access can expose bad things
well-defined patch cadence patch management decentralized

NoSQL problem

NoSQL solutions were never intended for internet exposure
BUT (naturally) peoples exposed them to internet.

Hunting NoSql Compromise in Azure

Port scans are slow and each NoSQL solution runs on different ports.

The author used shodan:

  • rich metadata for each IP
  • DB names are indexed
  • JSON export allows for automated hunting

The code was added to shodan in dec 2017 but requires shodan enterprise api access.

Network Security Group

Network Security Group is the VM firewall.

  • Configurable during deployment (optional)
  • 46% of images expose ports by default
  • 96% expose more than management

Your Iaas security is your responsibility
Pass and Saas are shared responsibility

  • Patches handled by Microsoft:
    • sas 100% transparent for you
    • paas requires configuration

Cloud marketplaces are supply chains

  • supply chain attacks are increasingly common.
  • cloud marketplaces are the next targets
  • minimal validation of 3rs party images
    • 3rd party iaas imaged are old
    • average azure age 140 days
    • average AWS Age: 717 days

2018 year of the cryptominer

  • cryptomining is the new ransomware
  • open s3 buckets are attacked
  • any vulnerable system is a target

 

Disrupting the Kill Chain (by Vineet Bhatia)

What is this talk about:

  • how to make the adversaries intrusion cost prohibitive.
  • how to monitor and secure Windows 10 environments.
  • how to recover from an intrusion.

Computer scientists at Lockheed-Martin corporation described a new “intrusion kill chain” framework; see KillChain.

PRE-ATT&CK: Adversarial Tactics, Techniques & Common Knowledge for Left-of-Exploit is a curated knowledge base and model for cyber adversary behavior, reflecting the various phases of an adversary’s lifecycle and the platforms they are known to target.

PRE-ATT&CK consists of 15 tactics and 151 techniques.

ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge for Enterprise is an adversary model and framework for describing the actions an adversary may take to compromise and operate within an enterprise network. The model can be used to better characterize and describe post-compromise adversary behavior.

Summary of the adversary behavior:

  • know when they are coming, use PRE-ATT&CK
  • see them when they operate on your infrastructure, use ATT&CK.
  • map their activities, use the “kill chain”.

Don’t jump directly to attacker remediation; If an adversary perceives you as hostile (e.g.: hacking back), they will react differently.

How to make intrusions cost prohibitive:

  • reduce attack surface area.
  • detect early and remediate swiftly.
  • deceive, disrupt and deteriorate.

The rest of the talk was about the windows10 security:

Hunting Android Malware: A novel runtime technique for identifying malicious applications (by Christopher Leroy)

Malware is a constant threat to the Android ecosystem. How to protect from the malware:

  • have to look to the APK file/s:
    • statically
    • or in a sandbox
  • looking for:
    • (code) signatures
    • hashes
    • permissions reputations

What are the shortcomings of the current detection techniques:

  • static analysis is hard and it only can reveal a subset of the functionality.
  • bypass the AV products is easy.
  • cannot do forensics on realtime.

Idea: look to the application heap because the Android apps make us of objects. But the novelty is that should instrument the code before the execution:

  • objects exist on the heap so they are accessible.
  • trace calls and monitor the behavior.
  • great way to gain insight into applications

The authors presented his own framework called UITKYK. Uitkyk is a framework that allows you to identify Android malware according to the instantiated objects on the heap for a specific Android process.

The framework is also integrates with Frida framework which is a “dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers”.

Exploits in Wetware (by Robert Sell)

This was also a talk about social engineering. From my point of view it does not bring new things comparing to the talk “Social engineering for penetration testers” from previous day.

Dissecting Of Non-Malicious Artifacts: One IP At A Time (by Ido Naor and Dani Goland)

The talk was about how can find very valuable information that is uploaded (accidentally or not) on different public cloud services.

 

 

 

(My) BruCON 2018 Notes (Retro Day)

Here are my quick notes from the BruCON 2018 conference.This first day was called “Retro Day” because it contained the best (as chosen by peoples) previous talks. All the slides of the conference can be found here.

Advanced WiFi Attacks using Commodity Hardware (by Mathy Vanhoef)

Wifi devices assume  that each device is behaving fairy,share the bandwidth with the other devices for example.

With special hardware it is possible to modify this behavior ; It is possible to do:

  • continous jamming; channel unusable.
  • selective jamming; block specific packets.

Implementing of selfish behavior using cheap devices

Steps to send a frame:
frame1 + SIFS + AIFSN + backoff + frame2

  • SIFS : represents the time to let the hardware process the frame.
  • Backoff :  random amount of time, used to avoid collisions.

Implement the selfish behavior (this was done by modifying the firmware):

  • disable Backoff.
  • reduce AIFSN.

Countermeasures to this problem:

  • DOMINO defense system detects selfish devices

What if are multiple selfish stations ?
in theory : in collision both frames are lost but in reality due to the “capture effect” in a collision the frame with best signal and lowest
bit-rate is decoded (similar to FM radio).

Continuous jamming

how it works:

  • instant transmit:disable carrier sense
  • no interruptions : queue infinite packets

This will
– only first package visible in monitor mode
– other devices are silcenced

What is the impact in practice:
We can jam any device that use the 2.4 and 5 GHz band, not only wifi, but other devices like security cameras.

Selective jammer

Decides based on the header whether the jam the frame
so it should:

  • detect and decode the header.
  • abort receiving current frame.
  • inject dummy packet

The hard part is the first step. This is done by monitoring the (RAM) memory written by the radio chip.

Impact of the attacks on higher layers

Breaking WPA2; this is a shorter version of :KRACKing WPA2 in Practice Using Key Reinstallation Attacks.

Hacking driverless vehicles (by Zoz)

Drivelless vehicles advantages:

  • energy efficiency
  • time efficiency

Main roadblocks:
– shared infrastructure (have to share road/s with card driven by humans)
– acceptance (safety robustness).

Classical failures:

  • RQ-3 DarkStar – self flying drone; it crashed due to cracks into the runway.
  • sandstorm ; self driving car contest: in this case the mismatch between GPS info and other sensor.

Autonomous vehicle logic structure:

Mission task planners
|
Navigation
|
Collision avoidance
|
Control lops

Sensors used by driveless vehicles:

  • active vs passive sensors
  • common sensors:
    • gps
    • lidar
    • cameras
    • wave radar
    • digiwheel encoderes

Sensor attacks

2 kinds:

  • denial
  • spoofing – craft false data

GPS:

  • denial – jamming
  • spoofing – fake GPS satellite signals

LIDAR

  • denial:
    • active overpowering
    • preventing returning signal
  • spoofing
    • can fake road markings invisible to humans
    • can make solid looking objects

Digital compass:

  • extremely difficult to interfere with acoustic attacks.
  • gyroscope vibrates and has a resonance frequency.

Levelling Up Security @ Riot Games (by Mark Hillick)

The talk was structured in 2 parts; what RiotGames do/did to enhance security in 2015 and what they are doing to enhance security in 2018

2015

  • introduced the idea of security champion.
  • introduced the RFC (Review For Commens) document = Technical Design.
    • not an approval process it’s more about receiving advice
    • becomes a standards through adoption.
    • introduction of bug bounty program.

2018

  • security team had doubled in size.
  • sec-ops team and read team are working together.
  • put in place an anti-cheating strategy:
    • prevention
    • detection
    • deterence

Top8 vulnerabilities:

  • improper authentication.
  • open redirect.
  • information disclosure.
  • business error.

Challenges around secrets:

  •  detected an api key from AWS in a commit.
  • how to fix it.
    • provide temporary AWS API token
    • remove the usage of long-lived AWS Api keys.

Social engineering for penetration testers (by Sharon Conheady)

Definition: efforts to influence popular attitudes and social behavior.

Main take away (for 2018); the social engineering (a.k.a SE) is used more and more and actually the techniques it didn’t change too much.

what has changed since 2009 ?
nothing

example of social enginnering through history:

What had changed since 2009 (when the same talk has been given):

  • the scale of the attacks.
  • sophistication
  • more targeted
  • ethical SE is mostly phishing.

Why social engineering (still) works:

  • peoples want to help.
  • greed
  • tendency to trust
  • complacency
  • peoples do not like confrontations.

Stages of an attack

  • target identification
  • reconnaissance
    • passive information gathering
    • physical reconnaissance
    • google map
    • where are the security guards
  • sample scenarios
    • tailgate
  • going in for the attack
    • use your scenario to get in
    • prove you were there
    • have an exit strategy
  • write the report
  • tell the story

The 99c heart surgeon dilemma (by Stefan Friedli)

The presentation was about pen test bad examples and how to make the things better.

It starts with examples of bad pen test:

  • Unclear impact metrics.
  • Accidentally pasting other customer names.
  • Reported false positives.

How to make the things better:

  • Avoid security companies offering bad services. How:
    • Ask about procedures, standards.
    • Ask to talk to the testers
    • Check for community participation
    • Look at sample deliverables
  • How to fix Penetration Testing:
    • Involve more people.
    • Have more conversations.
    • Don’t stop at the report

(My) OWASP Belgium Chapter meeting notes

These are my notes of OWASP Belgium Chapter meeting of 17th of September.

Docker Threat Modeling and Top 10 (by Dirk Wetter)

Docker not really new:

  • FreeBSD – Jails year 2000
  • Solaris : Zones/Container year 2004

Threat Vectors on the (Docker) containers:

  1. Application escape
  2. Orchestration tool
  3. Other containers
  4. Platform host; especially after the discovery of vulnerabilities into microprocessors (Spectre, Foreshadow).
  5. Network: not properly secured network.
  6. Integrity and confidentiality of OS images.

Top 10 Docker security

  1. Docker insecure default running code as privileged user
    • workaround : remap user namespaces user_namespaces (7)
  2. Patch management
    • Host
    • Container Orchestration
    • OS Images
  3. Network separation and firewalling
    • use basic DMZ techniques
    • allow only what is needed on the firewall level
    • (for external network connection) do not allow initiating outgoing TCP connections.
  4. Maintain security contexts
    • do not mix Development/Production images
    • do not mix Front-End and Back-End services
    • do not run arbitrary images.
  5. Secrets management
    • where to store keys, certificates, credentials
    • not easy to solved problem
  6. Resource protection
    • limit memory (--memory=), swap (memory-swap=), cpu usage (--cpu-*), --pids-limit xx
    • do not mount external disks if not necessary, if really necessary then mount it as r/o.
  7. Image integrity and origin
  8. Follow the immutable paradigm
    • run the container in read only mode: docker run --read-only... or docker run –v /hostdir:/containerdir:ro
  9. Hardening
    • Container
      • docker run --cap-drop option, you can lock down root in a container so that it has limited access within the container.
      • --security-opt=no-new-privileges prevents the uid transition while running a setuid binary meaning that even if the image has dangerous code in it, we can still prevent the user from escalating privileges
    • Host
      • networking – only SSH and NTP
  10. Logging

Securing Containers on the High Seas (by Jack Mannino)

The entire presentation is around the 4 phases used to create an application that runs on containers:

  • Design
  • Build
  • Ship
  • Run

Design (secure the design)

  • Understand how the system will be used and abused.
  • Beware of tightly-coupled components.
  • Can solve security issues through patterns that lift security out of the container itself. ex Service Mesh Pattern.

Build (secure the build process)

  • Build first level of security controls into containers.
  • Orchestration systems can override these controls and mutate containers through an extra layer of abstraction.
  • Use base images that ship with minimal installed packages and
    dependencies.
  • Use version tags vs. image:latest; do not use latest !
  • Use images that support security kernel features
  • Limit privileges
    • Often, we only need a subset of capabilities
      • ex: Ping command requires CAP_NET_RAW. So we can run docker image like this:

docker run -d --cap-drop=all --cap-add=net_raw my-image

  • Kernel Hardening
    • Seccomp is a Linux kernel feature that allows you to filter dangerous syscalls.
  • MAC (Mandatory Access Control)
    • SELinux and AppArmor allow you to set granular controls on files and network access.
    • Docker leads the way with its default AppArmor profile.

Ship

  • Validate the integrity of the container.
    • ex: Docker Content Trust & Notary
    • Consume only trusted content for tagged Docker builds.
  • Validate security pre-conditions.
    • Allow or deny a container’s cluster admission.
    • Centralized interfaces and validation.

Run

  • Containers are managed through orchestration systems.
  • Management API – used to deploy, modify and kill services.
    • Frequently deployed without authentication or access control.
  • Authentication
    • Authenticate subjects (users and service accounts) to the cluster.
    • Avoid sharing service accounts across multiple services.
    • Subjects should only have access to the resources they need.
  • Secrets management
    • Safely inject secrets into containers at runtime.
    • Anti-patterns:
      • Hardcoded.
      • Environment variables.

How to write a (Java) Burp Suite Professional extension for Tabnabbing attack

Context and goal

The goal of this ticket is to explain how to create an extension for the Burp Suite Professional taking as implementation example the “Reverse Tabnabbing” attack.

“Reverse Tabnabbing” is an attack where an (evil) page linked from the (victim) target page is able to rewrite that page, such as by replacing it with a phishing site. The cause of this attack is the capacity of a new opened page to act on parent page’s content or location.

For more details about the attack himself you can check the OWASP Reverse Tabnabbing.

The attack vectors are the HTML links and JavaScript window.open function so to mitigate the vulnerability you have to add the attribute value: rel="noopener noreferrer" to all the HTML links and for JavaScriptadd add the values noopener,noreferrer in the windowFeatures parameter of the window.openfunction. For more details about the mitigation please check the OWASP HTML Security Check.

Basic steps for (any Burp) extension writing

The first step is to add to create an empty (Java) project and add into your classpath the Burp Extensibility API (the javadoc of the API can be found here). If you are using Maven then the easiest way is to add this dependency into your pom.xml file:

<dependency>
    <groupId>net.portswigger.burp.extender</groupId>
    <artifactId>burp-extender-api</artifactId>
    <version>LATEST</version>
</dependency>

Then the extension should contain  a class called BurpExtender (into a package called burp) that should implement the IBurpExtender interface.

The IBurpExtender  interface have only a single method (registerExtenderCallbacks) that is invoked by burp when the extension is loaded.

For more details about basics of extension writing you can read Writing your first Burp Suite extension from the PortSwigger website.

Extend the (Burp) scanner capabilities

In order to find the Tabnabbing vulnerability we must scan/parse the HTML responses (coming from the server), so the extension must extend the Burp scanner capabilities.

The interface that must be extended is IScannerCheck interface. The BurpExtender class (from the previous paragraph) must register the custom scanner, so the BurpExtender code will look something like this (where ScannerCheck is the class that extends the IScannerCheck interface):

public class BurpExtender implements IBurpExtender {

    @Override
    public void registerExtenderCallbacks(
            final IBurpExtenderCallbacks iBurpExtenderCallbacks) {

        // set our extension name
        iBurpExtenderCallbacks.setExtensionName("(Reverse) Tabnabbing checks.");

        // register the custom scanner
        iBurpExtenderCallbacks.registerScannerCheck(
                new ScannerCheck(iBurpExtenderCallbacks.getHelpers()));
    }
}

Let’s look closer to the methods offered by the IScannerCheck interface:

  • consolidateDuplicateIssues – this method is called by Burp engine to decide whether the issues found for the same url are duplicates.
  • doActiveScan – this method is called by the scanner for each insertion point scanned. In the context of Tabnabbing extension this method will not be implemented.
  • doPassiveScan – this method is invoked for each request/response pair that is scanned.  The extension will implement this method to find the Tabnabbing vulnerability. The complete signature of the method is the following one: List<IScanIssue> doPassiveScan(IHttpRequestResponse baseRequestResponse). The method receives as parameter an IHttpRequestResponse instance which contains all the information about the HTTP request and HTTP response. In the context of the Tabnabbing extension we will need to check the HTTP response.

Parse the HTTP response and check for Tabnabbing vulnerability

As seen in the previous chapter the Burp runtime gives access to the HTTP requests and responses. In our case we will need to access the HTTP response using the method IHttpRequestResponse#getResponse. This method returns a byte array (byte[]) representing the HTTP response as HTML.

In order to find the Tabnabbing vulnerability we must parse the HTML represented by the HTML response. Unfortunately, there is nothing in the API offered by Burp for parsing HTML.

The most efficient solution that I found to parse HTML was to create few classes and interfaces that are implementing the observer pattern (see the next class diagram ):

 

The most important elements are :

The following sequence diagram try to explains how the classes are interacting  together in order to find the Tabnabbing vulnerability.

Final words

If you want to download the code or try the extension you can find all you need on github repository: tabnabbing-burp-extension.

If you are interested about some metrics about the code you can the sonarcloud.io: tabnnabing project.

 

 

(My) OWASP Belgium Chapter meeting notes

These are my notes of OWASP Belgium Chapter meeting of 19th of March.

KRACKing WPA2 in Practice Using Key Reinstallation Attacks (by Mathy Vanhoef)

This talk subject was about the attack on the WPA2 protocol that was made the (security) headlines last year. The original paper can be found here and the slides can  be found here.

The talk had 4 parts :

  • presentation of the attack.
  • practical impact
  • common misconceptions
  • lesson learned

 Presentation of the attack

The 4-way handshake is used in any WPA2 protected network. His use if for mutual authentication and to negotiate a new pairwise temporal key (PTK).

The messages sent between the client and the access point (AP) are the following ones:

 

The PTK is computed in the following way: PTK = Combine (shared secret, ANonce, SNonce) where ANonce, SNonce are random numbers.

Re-installation attack:

  • the attacker will clone the access point on different channel.
  • the attacker will/can forward or block frames.
  • the first 3 messages are sent back to client and AP.
  • message 4 is not sent to the AP; the attacker block this, and the client install the PTK (as per protocol specification)

  • client can sent encrypted data but the AP will try to recover from this by re-sending message 3.
  • then the client will reinstall the PTK meaning that will reset the nonce used to send encrypted data.

  • the effect of this key re-installation is that the attacker can decrypt the frames sent by the client.

Other types of handshake protocols are vulnerable to this kind of attack:

  • group key handshake.
  • fp handshake.

Practical impact of the attack

The main impact is that the attacker can decrypt the data frames sent by the victim to the AP (access point) and the attacker can replay frames sent to the victim.

  • iOS 10 and Windows, the 4-way handshake is not affected (because they are not following the WPA2 specification), but the group key handshake is affected.
  • Linux and Android 6.0+ that are using the wpa_supplicant 2.4+ version are exposed to install all-zero key vulnerability. The basic explanation of the vulnerability is the following one; the application do not keep the key, the PTK is installed at the kernel level and the application will zeroed the memory buffer that contains the key. But when the key re-installation is triggered, then the all-zero key will be sent to the kernel to be installed.

Countermeasures:

  • AP (access point) can prevent most of the attacks on clients:
    •  Don’t retransmit message 3/4.
    • Don’t retransmit group message 1/2.

Common missconceptions

  • update only the client or AP is sufficient.
    • in fact both vulnerable clients & vulnerable APs must apply patches
  • must be connected to network as attacker.
    • in fact the attacker only need to be nearby victim and network.

Lessons learned

4-way handshake proven secure AND encryption protocol proven secure BUT the combination of both of them was not proven secure.
This proves the limitation of formal proofs so abstract model ≠ real code.

Making the web secure by design (by Glenn Ten Cate and Riccardo Ten Cate)

This talk was about the new version of the OWASP SKF.  I already covered  the SKF in some of my previous tickets (see here and here) so for me was not really a novelty. The main changes that I was able to catch comparing with the previous version :

(My) CSSLP Notes – Software Deployment, Operations, Maintenance and Disposal

Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and Official (ISC)2 Guide to the CSSLP CBK, Second Edition

Installation and deployment

CSSLP-logoInstallation and deployment activities are implemented following a plan which can be used to document best practices. The software needs to be configured so that the security principles are not violated or ignored during the installation.

Some steps necessary in pre-installation or post-installation phases:

  • Hardening – Harden the host operating system by using the Minimum Security Baseline (MSB), updates and patches; also harden the applications and software that runs on top of the operating system.
  • Environment Configuration – pre-installation checklists are useful to ensure that the needed configuration parameters are properly configured.
  • Release Management – Release management is the process of ensuring that all the changes that are made to the computing environment are planned, documented, tested and deployed with least privilege without negatively impacting any existing business operations or customers.
    • Bootstrapping and secure startupBootstrapping (or booting) involves any one shot process that ensures the correctness of the initial configuration; this includes the the proper defaults and execution parameters. Secure startup refers to the entire collection of processes from the turning on of the power until the operating system is in complete control of the system.The use of TPM (Trusted Platform Module) chip enables significant hardening of startup parameters from tampering.

Operations and Maintenance

The purpose of the software operations process is to operate the software product in its intended environment; this implies a focus on the assurance of product effectiveness and product support for the user community.

The purpose of the software maintenance process is to provide cost-effective modifications and operational support for each of the software artifacts in the organizational portfolio.

Activities that are useful to ensure that the deployed software stays secure:

  • Monitoring – As part of the security management activities, continuous monitoring is critically important. The task is accomplished by: scanning, logging, intrusion detection.
  • Incident Management – The incident response management process applies whether the organization is reacting to a foreseen event or is responding to an incident that was not anticipated. The key to ensuring effective response is a well defined and efficient incident reporting and and handling process.
  • Problem ManagementProblem management is focus on improving the service and business operations. The goal of problem management is to determine and eliminate the root cause of an operational problem and in doing so it improves the service that IT provides to the business.
  • Change Management – Change Management includes also Patch and Vulnerability Management. The main goal of the change management is to protect the enterprise from the risk associated with changing of functioning systems.
  • Backup, Recovery and Archiving – In addition to regularly scheduled backups, when patches and software updates are made, it is advisable to perform full backup of the system that is being changed.

Secure Software Disposal

The purpose of the secure software disposal process is to safely terminate the existence of a system or a software entity. Like all formal IT processes, disposal is conducted according to a plan, that defines schedules, actions and resources.

Supplier Risk Assessment

The overall purpose of the supplier risk assessment is to identify and maintain an appropriate set of risk controls within the supply chain.

Categories of concerns for an external supplier:

  • installation of malicious logic in hardware or software.
  • installation of counterfeit hardware or software.
  • failure or disruption in the production of distribution of a critical product or service.
  • installation of unintentional vulnerabilities in software or hardware.

All the software items moving within a supply chain have to comply with existing laws and regulations.

(My) OWASP BeNeLux Days 2017 Notes – Training Day

These are my notes from the OWASP BeneLux Days 2017 on “Secure Development: Models and best practices” by Bart De Win.

The goal of the training was about how to improve the structure of an organization in order to enhance the security of (IT) applications.

The talk was around the following topics:

  • Software assurance maturity models
  • Introduction to SAMM and hands-on exercise/s
  • Secure Development in agile development
  • Tip and tricks for practical SDLC
  • Sneak preview of SAMM 2.0

Software assurance maturity models

Today we build more and more complex software:

  • multi platform;
  • mobile version; cloud
  • same application using different technological stacks

75% of vulnerabilities are application related

The state of the Secure Development LifeCycle (SDLC) today:

  • on focus on bugs not an (architectural) flows
  • (very often) do pen test just before going in live

The goal of  the SDLC is to develop and maintain software in a consisted and efficient way with  standards-compliance security quality.

SDLC Cornerstones:

  • peoples
  • process
    • activities
    • control gates
    • deliverables
  • knowledge
    • standards&guidelines
    • compliance
  • tools&component
    • development support
    • assessment tools
    • management tools

Introduction to SAMM and hands-on exercise

SAMM is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks faced by an organization.

Other standards/frameworks that are in the same space as SAMM:

SAMM consists in 4 business functions each one containing 3 security practices. Each security practice have 4 maturity levels (from 0 to 3):

Each (SAMM) maturity level defines the following attributes:

  • objectives
  • activities
  • results
  • success metrics
  • cost
  • personnel
  • related levels

How do we start with SAMM: It is possible to start with the SAMM Toolbox Excel file in order to do an initial assessment for each of the  security processes (the Excel file will compute the maturity level). This initial assessment will help you to plan the improvements.

Secure Development in agile development

There are a mismatch between the agile development goal/s and the security goal/s

agile dev security
  • speed and flexibility
  • short cycles
  • limited documentation
  • functionality driven
  • stable and rigorous
  • extra activities
  • extensive analysis
  • non functional

Introducing security into agile development is not easy task and especially there is not a standardized way of doing it.

Some ideas and hints:

  • make security a natural part of the process
  • capture security requirements, policies and regulations in user stories

Sneak preview of SAMM 2.0

  • planned for end of next year.
  • model revision
  • more metrics
  • application to agile
  • benchmarking