Security

Book review: Software Security: Building Security in – Part I: Software Security Fundamentals

Adrian Citu

This is a review of the first part of the Software Security: Building Security in book.

Chapter 1: Defining a disciplineSecuritySoftwareBookCover

This chapter lands out the landscape for the entire book; the author presents his view on the today challenges in having secure holes free software.
In the today world, the software is everywhere, from microwaves oven to nuclear power-stations, so the “old view” of seeing the software applications as “black boxes” than can be protected using firewalls and IDS/IPS it’s not valid anymore.

And just to make the problem even harder, the computing systems and the software applications are more and more interconnected must be extensible and have more and more complex features.

The author propose a taxonomy of the security problems that can be affected the software applications:

  • defect: a defect is a problem that may lie dormant in software only to surface in a fielded system with major consequences.
  • bug: an implementation-level software problem; only fairy simple implementations errors. A large panel of tools are capable to detect a range of implementation bugs.
  • flaw: a problem at a deeper level; a flow is something that can be present at the code level but it can be also present or absent at the design level. What is very important to remark is that the automated technologies to detect design-level flows do not yet exist, through manual risk-analysis can identity flows.
  • risk: flaws and bugs lead to risk. Risk capture the chance that a flaw or a bug will impact the purpose of a software.

In order to solve the problem of the software security, the author propose a cultural shift based on three pillars: applied risk management, software security touchpoints and knowledge.

Pillar 1 Applied Risk Management

For the author under the risk management names there 2 different parts; the application of risk analysis at the architectural level (also known as threat modeling or security design analysis or architectural risk analysis) and tracking and mitigating risks as a full life-cycle activity (the author call this approach, the risk management framework – RMF).

Pillar 2 Software security Touchpoints.

Touchpoint it’s just a fancy word for “best practices”. Today there are best practices for design and coding of software system and as the security became a property of a software system, then best practices should also be used to tackle the security problems.Here are the (seven) touch points and where exactly are applied in the development process.

Security Touchpoints
Security Touchpoints

The idea is to introduce as deeply as possible the touch points in the development process. The part 2 of the book is dedicated to the touchpoints.

Pillar 3 Knowledge

For the author the knowledge management and training should play a central role in encapsulation and sharing the security knowledge.The software security knowledge can be organized into seven knowledge catalogs:

  • principles
  • guideline
  • rules
  • vulnerabilities
  • exploits
  • attack patterns
  • historical risks

How to build the security knowledge is treated in the part 3 of the book.

Chapter 2: A risk management framework

This chapter presents in more details a framework to mitigate the risks as a full lifecycle activity; the author calls this framework the RMF (risk Management Framework).

The purpose of the RMF is to allow a consistent and repeatable expert-driven approach to risk management but the main goal is to find, rank, track and understand the software security risks and how these security risks can affect the critical business decisions.

Risk Management Analysis steps
Risk Management Analysis steps

The RMF consists of five steps:

  1. understand the business context The goal of this step is describe the business goals in order to understand the     types of software risks to care about.
  2. identify the business and technical risks. Business risk identification helps to define and steer the use of particular technological methods for measuring and mitigating software risk.The technical risks should be identified and mapped (through business risk) to business goals.
  3. synthesize and rank the risks. The ranking of the risks should take in account which business goals are the most important, which business goals are immediately threatened and how the technical risks will impact the business.
  4. define a risk mitigation strategy. Once the risks have been identified, the mitigation strategy should take into account cost, implementation time, likelihood of success and the impact
  5. carry out required fixes and validate that they are correct. This step represents the execution of the risk mitigation strategy; some metrics should be defined to measure the progress against risks, open risks remaining.

Even if the framework steps are presented sequentially, in practice the steps can overlap and can occur in parallel with standards software development activities. Actually the RMF can be applied at several different level; project level, software lifecycle phase level, requirement analysis, use case analysis level.

Threat Modeling for mere mortals

Adrian Citu

This ticket is an introduction to the threat modeling in the context of software development.

Definition

In the context of the IT security, threat modeling is a structured approach that enables you to identify, quantify, and (eventually) address the security risks associated with an application.

A more formal definition

 For somebody having the security mindset the previous definition might be not very formal; let’s try a new definition but before let’s introduce some new definitions:

  • asset  – an asset is what it must be protected. In the context of software, it could be the infrastructure, the software installed, the user data.
  • vulnerability – a vulnerability is a weakness that can be present in one of the assets.
  • threat – anything that can exploit a vulnerability and obtain, damage, or destroy an asset.
  • risk – the potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability.

So, the threat modeling (also sometimes called risk analysis or architectural risk analysis) is the process integrated in the SDLC (Software Development Life Cycle) having as goal to find and address (mitigate, eliminate, transfer or accept) all possible risks for a specific software functionality.

The threat modeling should be applied in the SDLC as early as possible, ideally in the requirements phase (the earliest the problems will be found the easiest would be to fix) and could even modify or adjust the requirements.

The threat modeling process

The threat modeling process have 3 phases:

  1. model the system for which you want to find the threats.
  2. find the threats.
  3. address each threat found in the previous step.

1. Model the system

The goal is to have a diagram representing the system under process. In the specialized literature, the Data Flow Diagrams are very often used because it easily represent all interaction points that an adversary can leverage to attack a system and also show how data moves through the system. The diagram could be improved adding “trust boundaries”, boundaries where data changes its level of “trust”.

2. Find the threats

After having a diagram of the system then you can ask how an attacher could attack the system. There are different approached that can be used to find “what can go wrong”:

  • STRIDE –this methodology (created by Microsoft) classifies threats into 6 groups:Spoofing, Tampering, Repudiation,
    Information Disclosure, Denial of Service and Elevation of Privilege.
    Threat Modeling is executed by looking at each component of the system and determines if any threats that fall into these categories exist for that component and its relationships to the rest of the system.
  • Threat/Attack libraries – libraries containing common and already known attacks. Threat library can be a quick way to take advantage of industry security knowledge (helping teams that lack sufficient knowledge themselves). Some examples of Threat libraries: OWASP Top Ten, CAPEC, CWE.
  •  Misuse cases – These cases should be derived from the requirements of the system, and illustrate ways in which protective measures could be bypassed, or areas where there are none.

3. Addressing the threats

Once identified,each threat must be evaluated according to the risk attached to it (using a risk rating system such as Common Vulnerability Scoring System), the resources available,the business case and the system requirements.

This will help prioritize the order in which threats should be addressed during development, as well as the costs involved in the mitigation  (if you decide to mitigate it).

Not all the treats can be mitigated. It is also possible to decide that some of them should be eliminated (meaning that the feature of the functionality that if affected should be removed), transfered (let somebody or something else to handle the risk) or accepted (accept the risk that could happen).

If you want to go further

If you want to go further and dig deeper hare are some links that I found useful:

(My) BruCON 2015 notes (5)

Adrian Citu

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

This is the last ticket about the BruCOn 2015 so, it contains the presentations for which my notes are not so good 🙂

Creating REAL Threat Intelligence with EvernotebruCon

goal:

  • experiment to generate threat intelligence with Evernote.
  • use Evernote as intelligence repository.

background:

  • before buying new commercial solution
    • try quick and dirty solution in house
    • invest in people &process first, then Products.

Use Evernote as a GTD(Getting Things Done ??)-Based Task Mgmt System.

  • treat  Evernote like  a  Database
    • Notebook  ==  Table
    • Note  ==  Free  Form  Record
    • Nested  Notebooks
    • Hierarchical  Tags

Looking Forward – Finding the right balance for INFOSEC

Some words about the infosec in the past and today:

  • in 1999 the security community was a small community
  • things start to change now BUT
    the ratios security/it people it’s very low

Some words about the security breaches:

  • 99% of the breaches is are due to basic things; BUT the companies are focusing on much complicated
    attacks but are forgetting the easy to fill gaps.
  • end-users are still the weakest link; for fishing only one click it’s enough to get in inside the it infrastructure
  • profiling is difficult BUT targeting the user is muck more easier.

Some words about the security industry:

  • security industry is too technology centric.
  • we just hope that the technology will solve the problems magically.
  • technology it takes over talent.

Some ideas for the defence:

  • Disabling local administrator accounts, or randomizing.
  • Rotating domain admin account passwords.
  • Disallow PowerShell execution for normal users.
  • Disallowing executables to be run through TEMP and other directories.
  • Network segmentation of user workstations.
  • Focus on detection capabilities over anything.

I am the Cavalry

The Cavalry is a organization that is focused on issues where computer security intersect public safety and human life. The areas of focus for The Cavalry are medical devices, automobiles, home electronics and public infrastructure.

How to influence people (a pen test like approach):

  • recon
  • empathizing (replaces finding vulnerabilities)
  • enabling changes (replaces exploitation)

Recon

known the official structure and the non-official one.

unofficial structure

  • who is liked
  • trusted influencers

Empathizing

  • understand the stakeholders
  • studies can give you a hint about the way of thinking
  • motivation, career ambitions
  • how the stakeholders make decisions
  • learn how to speak the stakeholders language – cross domain issues

Enabling changes

  • work the system;
  • be adaptive if it didn’t worked
  • riding waves, news
  • speak their language

(My) BruCON 2015 notes (4)

Adrian Citu

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

The malware is just code so, as any other code it is possible (in theory) to analyze/reverse engineer it manually.

The triage is one of the functions of the incident response program and must answer the following three questions regarded to a specific input:

  • is the input malicious ?
  • if yes, what is exploiting ?
  • are we exposed ?

Triage is not malware analysis and should be quick and efficient. The triage workflow:

  • passive analysis.
  • first interaction and download.
    • some malware are crafted to be able to interact with the initial URL only limited number of times
    • some malware could profile your browser, check the browser version, platform, or use the user agent script to decide if the exploit can be executed or not.
    • some tools:useragentstring.com (to check your user agent), onlinecurl.com (on-line version of curl, copy paste a url and you get back the response), hurl.it (idem as previous one).
  • web component analysis.
    • once you have the web component (which is typically an html page + JavaScript) you could try to analyze it.
    • use jsBeautify.org to try to have something human readable in case the code is obfuscated.
    • try to use the browser debugger, eventually change JavaScript eval expressions.
  • exploit analysis.
    • can use showmycode.com to understand the exploit; it is capable to decompile Java, Flash, .Net, PHP
    • sometimes you can blindly search the metasploit exploit template library
  • payload extraction.
  • payload analysis.
    • can submit the file/s to VirusTotal or malwr (virtualized Cuckoo instances).
    • malwr can give you infos about the registry keys created, network traffic.
  • build IOCs (Indication Of Compromise).
    • collection of indicators which can be used to describe a compromised system.

This was an workshop, so the participants had to play with some of the tools. Here is the quick workflow that i followed:

start from a url -> use the onlinecurl.com to get the response (initial interaction) -> saved the response on a file and used to browser debugger to understand what the component is doing (web component analysis)-> get from the JavaScript another url that contains a link to a Java .class file -> use it showmycode.com to decompile the class file (exploit analysis)-> write some Java code to decode parts of the exploit and execute it on ideone.com (payload extraction)-> …time over :(.

(My) BruCON 2015 notes (3)

Adrian Citu

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

Intrusion detection on Linux and OSX with osquery

osquery goals:

  • explore your operation system using sqlbruCon
  • host visibility is motivated by intrusion detection
  • wanted 1 binary; 6MB with no dependencies
  • done in C++
  • created and used by facebook (installed on 60 000 osx)

Same osquery query examples:

  • select pid, name, uid from processes where [constraints]
  • the sql syntax is the SQL lite  syntax.
  • no Windows version; linux and osx only.
  • a lot of cool examples: the list of events that happened on the host (files changed, usb sticks inserted).

A second binary that is presented is called osqueryd. osqueryd is a daemon; it uses a json-config config file to set options and define a schedule. The goal of osqueryd is to execute queries peridically and then send the result to an ELK (ElasticSearch+LogStash+Kibana) system.

The queries used by Facebook are packaged in different files; these packages can be also downloaded free of charge.

Kernel Tales: Security Testing of aarch64 Android Kernels

A kernel contains code from various sources; hardware manufacturers, software companies (google, samsung).
An Android kernel is almost a Linux kerner, so the attack surface is through syscalls;
The way to corrupt the kernel: the user space tries to write in the kernel space by using syscalls or even better use the ioctls to replace the syscall.

The overall idea is to fuzzy the parameters passed to ioctls. The fuzzer used (dronity) is based on the trinity fuzzer; dronity is not yet available (it will be soon on github).

The demo contained the following items:

  • dronity fuzzing a Android development board.
  • dronity fuzzing a real Android tablet.
  • dronity fuzzing an aarch64 kernel on qemu.
  • dronity fuzzing an aarch64 kernel with gdb attached (on qemu) in order to intercept the exception thrown by the kernel.