BinaryMist Approach To Threat Modelling

Kim Carter edited this page Jun 14, 2015 · 40 revisions

For best results: To be consumed as part of the BinaryMist ltd workshop with other content supplied.

Target Audience:

  • Software Architects
  • Software Developers/Engineers
  • Product Owners

If your looking to save money and save face due to potential embarrassment because your business assets have been compromised, continue reading. If your looking to become better at delivering secure solutions, continue reading.

Traditionally security has often been applied at the end of projects where it's most costly in the development life cycle to re-design and re-deploy. This is why security, in fact quality in general, is often seen as being to expensive and corners are cut.

Moving much of the focus of labour intensive and costly security assessments and tests being performed by deeply specialised security consultants to automated approaches that can be crafted by the Development Team within each Sprint.

The processes and practices I'm going to introduce will help you reduce (the most likely to be compromised (thus removing wasted effort)) security defects at the earliest possible point in time. Right where they are introduced. Iterate on Design -> Build -> Break, at every point of the development life cycle. Including within each Sprint for each Product Backlog Item (PBI) that's pulled into work in progress (WIP). We become good at what we do by failing fast in development, fixing it, then trying again. This same strategy applies to all areas of life.

Don't wait until you're on the stage, where the cost of your mistakes are at their highest.


The crux of the Bruce Schneier Sensible Security Model (SSM) can be found here.

"MS" identifies a Microsoft resource. "OWASP" identifies an "Open Web Application Security Project" resource.

Iterate on the 30,000' view, then iterate on each of the 10,000' views that are applicable for your specific domain and system.

At this stage a lot of the content is in an external presentation to be delivered at CampJS


Where ever you see the following fiddling devil. It means there's a hands on attack demo coming up:

Hands On Hack

Starting with the 30,000' view

30,000' view

This modelling process should be performed by a collection of the following people:

  1. Deeply technical (software expert (developer/engineer)). I specifically don't mention tester(s) here, as testing is the job of the developer. The developer is responsible for delivering high quality working code every Sprint.
  2. Network expert(s)
  3. Domain expert(s)
  4. The person solely responsible for the project or product being delivered
  5. Person(s) with security specialisations in the areas involved in the finished product. Remember you need to step back in order for your peripheral vision to kick in.

Having this process performed by a team brings out the best in everyone. There are of course times when it's more effective to break out and work alone for a period of time.

1. SSM Asset Identification

Assets will often emerge as you progress through the following steps.

2. SSM Identify Risks

threat agents opponents

Then think about some of the relationships the target business depends on...
How they could be leaking IP.

how might your threat agents gain access

and the Intel Threat Agent Library

Keep your eye on the vulnerability advisories:

3. SSM Countermeasures

4. SSM Risks that Solution Causes

This is really dependent on the solution(s) you discover.

  • Make sure before you test that you have written permission for all the areas that you're about to test, documenting what could possibly go wrong.
  • Make sure you have backups and that they work.
  • Complacency?
  • Spending too much on technological solutions and ignoring the fact that the person on the front desk can easily be tricked to reveal information an attacker needs or lower the defences of a computer system. See the section on People.

5. SSM Costs and Trade-offs

I'm not here to do the work for you, but rather to help you do it.

Give a man a fish and feed him for a day. Teach a man to fish and feed him for life

This is really dependent on the solution(s) you discover.

Counter-Measures costs - vs - Breach Costs

10,000' view and lower

Now that we've iterated on the 30,000' view, lets start honing in on the specific areas at a 10,000' view and lower.
One of the defining factors between the 30,000' and 10,000' views is when the process is carried out. The 30,000' should be carried out up front and possibly at intervals during product development.
The 10,000' view should be carried out each Sprint for each PBI as it's pulled into WIP.

As I'm sure you're aware, there are many books and resources devoted entirely to each of the following sections. At this stage, most of my recent experience has been around Cloud/VPS, Network and Web Applications. I cut my teeth as a tester and software engineer in Mobile, but that was from 2002 - 2005. Technology has changed since then. The mistakes we're still making haven't.

The content in each of the following sections is going to be a little thin for starters. This is going to be a (WIP) living document.

10,000' view of Physical Security

The area of physical security is often over looked, especially by technical people, although in most cases, it's the easiest and simplest to circumvent and also the easiest and simplest to mitigate.

1. SSM Asset Identification

Take results from higher level Asset Identification. Remove any that are not applicable. Add any newly discovered.

2. SSM Identify Risks

You can take the same process that we did at the top level, but abstract the ideas and then solidify them on physical components. Some of the ideas will work, some wont.

Many times physical security is good, but it's compromised by the people problem. My wife used to do a lot of commercial cleaning and every night she would come home with new stories about how people were the weakest link when it came to security. Most of the time when physical security is breached there actually is no security, because people have failed the design.

I'm also a qualified carpenter and as part of my job when I was practising was often required to break into buildings when tenants had done the runner, so I know a few things about physical security as well. Even when doors and windows are locked, their security is fairly simple to compromise without damaging anything. Funnily enough, it was seldom required to force latches, bump or pick locks. There is always a path of least resistance, the lowest hanging fruit, because people are always the weakest link in any security solution.

Fortress Mentality

Easy Widespread Easy Severe

We see the same analogy of the candy bar (fortress) running through many areas of security.
Many organizations still adopt a fortress mentality, where everyone on the outside is bad and stuff on the inside is less dangerous,” said Brian Krebs, author of the Krebs on Security blog. “Years of experience has taught us that the biggest problems often stem from the fact that once something gets through the outer defenses, it’s often a cakewalk to move around the internal network unimpeded.
We not only see this principle applied to networks, but also physical security.

Internal Doors and Cabinets Left Unlocked

Easy Common Easy Moderate

Filing cabinets and other cupboards left unlocked or locked and keys or combinations put in obvious places.

Insecure Doors and/or Windows

Easy Widespread Easy Severe

Open doors, open windows. Uninteresting right, because there seems to be little challenge to mitigate. So little challenge that the vulnerability often gets ignored. Believe it or not, but it's often the cleaners responsibility to lock doors, windows and set alarms. I've discussed some of these types of threat agents here. Many places I've worked in have had double latched windows only single latched when I do the rounds just before I leave. It's very easy to pry a double latch window open from the outside that is single latched.

Computers Logged in and Unlocked

Easy Widespread Easy Severe

Computers logged in, not locked and even screens still turned on. Often with very sensitive material clearly displayed on the screens. This is very common. Again physical security is rendered useless due to the people problem.

RFID Tags

Average Uncommon Easy Severe

Then there's all the RFID cards, tags for accessing buildings, elevators, car parks, etc. Again, relatively easily exploitable with readers and cloners which you can buy for varying prices or build your own.


Of course there are many more, but I'm running out of time, so I'm going to move on for now and hopefully come back to this.

3. SSM Countermeasures

Fortress Mentality

Average

Harden internal attack vectors. BinaryMist takes the approach of De-perimeterisation. That's not relying on network firewalls or LAN segmentation. Hardening every layer (defence in depth) as though all other layers are weak and easily compromised. I've blogged and spoken about this on many occasions.

Internal Doors and Cabinets Left Unlocked

Easy

  1. Education
  2. Test that the education is taking effect.

Insecure Doors and/or Windows

Very Easy

Similar to Computers Logged in and Unlocked

Computers Logged in and Unlocked

Easy

Most of what you can do here comes down to the people problem:

  1. Educating your workers
  2. Creating a culture that thinks about security and includes it as part of who they are
  3. Test your workers. Measure the results. Make sure your investment is falling on fertile ground and actually taking root. Adjust your training and change techniques to address weak areas. Measure again. Keep iterating on this.
  4. Again simple stuff, but from my experience, if your organisation falls into this bucket, until an attacker takes advantage of this, management seems blissfully unaware. So... If you see it, put your change agent skills to work. This can take significant cultural change. Be patient and make that change move from ground up. It doesn't matter where you sit in the organisations hierarchy. If you don't really know where to start, I'd recommend grabbing a copy of Fearless Change. It's not about meetings and presentations by the way. I've gained a lot of insight on how to gently change organisations and bring big improvements in many areas. I'd also recommend Nonviolent Communication by Marshall Rosenberg.

RFID Tags

Average

There are at least a couple of strategies to deal with RFID tag cloning

  1. Preventative.
    1. Multi-factor authentication. Fingerprint, PIN number or some other type of mechanism to verify that the person swiping the card/tag is actually the owner of it.
    2. There are all sorts of methods that the chip manufacturers and security community are using to make the cloning more costly in terms of time and effort.
  2. Detecting, reacting when it does happen. Methods such as:
    1. writing a new random number on the tag's memory every time it's scanned. When a tag is scanned with the same id as another tag that's been issued a new random number which is also recorded by the back-end, the back-end knows there is a duplicate tag.
    2. Video surveillance of the area where front-end (tag) to back-end (reader) communications are made

Keep in mind though, as Bruce Schneier said: "Detection works where prevention fails and detection is of no use without response."
As part of Identify Risks, you'll need to apply the ranking techniques discussed in order to decide the Likelihood, Impact on what's important to your business and all the other factors that the threat modelling techniques walk you through.
You can then use your ranking as input to the Countermeasures step. Thus helping you decide which, if any countermeasures are worth implementing.

4. SSM Risks that Solution Causes

Are there any? If so what are they?

5. SSM Costs and Trade-offs

An exercise for the reader. What are they?

10,000' view of IoT Security

Bruce Schneier has good insight on the problems to come I believe.

Todo

10,000' view of Mobile Security

Verint (a USA company) sells a cell phone tracking system called SkyLock with a subtitle of "Locate. Track. Manipulate" to both corporations and governments worldwide. SkyLock not only finds people but also tracks them over time periods.

The UK company Cobham sells a system that allows someone to send a "blind" call to a phone. A blind call doesn't ring and is not detectable by casual visual inspection of the phone. "The blind call forces the phone to transmit on a certain frequency, allowing the sender to track that phone to within one meter"

Then there's Infiltrator from Defentek, a real-time global tracking system that enables the end-user to monitor the targeted individual(s) activities and collect geo-location data to profile the subject(s) pattern of life and habits. This allows one too to derive to a plan of action or a motion for a warrant for further surveillance, investigation, apprehension, or decommissioning. Infiltrator claims to be able to locate and track any phone number in the world. with abilities such as being able to infiltrate and be undetected by the network, carrier or the target.

Many of the applications installed on our phones are collecting your personal information such as location, sex and your phones unique identification number (UID). Applications such as Angry Birds and even the flash-light app. Even apps that deliver bible quotes.

Tobias Engel discussed in his presentation at the 25th Chaos Communication Congress how to locate mobile phones using SS7. His slide deck is here. Recording of the presentation here. There are various open implementations that use the same technique such as Nicholas Skinner's PHP application.

There are many offerings available to allow people to spy on other individuals activities and location in regards to mobile phones. Even though the CEO and maker of StealthGenie which was a mobile app used for spying, was indicted and arrested for selling it in the USA, there are many other options for doing the same like HelloSpy, Highster, MySpy, FlexiSPY

The USA National Security Agency (NSA) and its UK counterpart, Government Communications Headquarters (GCHQ), use location data to track people.

Some resources to start with:
https://bluebox.com/business/bluebox-and-nist-addressing-mobile-threats/
https://media.blackhat.com/bh-us-12/Briefings/C_Miller/BH_US_12_Miller_NFC_attack_surface_WP.pdf

10,000' view of People Security

Like the section on Physical security, the people problem is often over-looked, not only by technical people this time, but by all. For a proficient social engineer, it's generally fairly easy to craft and execute attacks. Although not quite as easy and simple as walking through the front door that's left open. With a little patience, practice and the right frame of mind, the majority of people can be played successfully, even those that are very aware.

Why is it often over-looked? A couple of reasons I can think of.

  1. It's too simple
  2. Many of us don't like to put the spot-light on ourselves and look deep inside to try and find what makes us tick, what our flaws look like, why they exist, how we can re-architect the affected areas and in some cases work around them, but being aware of them. There is often real pain when we start poking and prodding at our inner weak areas.

As with many other attacks, this is often one that is a key component of a larger attack.

1. SSM Asset Identification

Take results from higher level Asset Identification. Remove any that are not applicable. Add any newly discovered.

2. SSM Identify Risks

Risks based on the failures of people present a very different set of attack vectors than any others mentioned in this material. People are both complex, complicated and our personalities are full of faults just waiting to be compromised, thus the approach at finding vulnerabilities is quite different.
You can still use some of the processes from 2. SSM Identify Risks, but the outcomes can look quite different.
I find the Threat agents cloud and Likelihood and impact diagrams still quite useful. Also MS 5. Document the Threats, OWASP Risk Rating Methodology and the intel-threat-agent-library as they're technology agnostic.
OWASP Ranking of Threats, MS 6. Rate the Threats and DREAD to a degree are useful.

People are the strongest point in a security process, they are often also the weakest.

Phone calls

Average Common Average Severe

With practice this can become reasonably easy to pull off, also with very little risk. Plus the social engineer (SE) can practice, practice, practice until they get the results they're looking for. If at first they don't succeed, then they can simply hangup and try again in a few days. Each attempt improving on what let them down last time.
As mentioned in Bruce Schneier's Beyond Fear: Convicted hacker Kevin Mitnick testified before Congress in 2000 about social engineering. “I was so successful in that line of attack that I rarely had to resort to a technical attack,” he said. “Companies can spend millions of dollars toward technological protections, and that’s wasted if somebody can basically call someone on the telephone and either convince them to do something on the computer that lowers the computers defences or reveals the information they were seeking.”
The government that imprisoned Kevin Mitnick for nearly five years, later sought his advice about how to keep its own networks safe from intruders.

Spoofing Caller Id

Easy WideSpread Difficult Low

This is arranging an impersonated identification (name or number) to be displayed on the receiving end of a phone that's in the state of receiving a call. The telephony providers don't perform authentication on whether the caller Id is valid or spoofed. To disambiguate, this is the caller Id and not the caller number.
This can be quite a useful confirmation for a social engineer to use as part of their pretexting. Caller Id spoofing has been around since at least 2004, with companies offering paid services like:

  • SpoofCard
  • SpoofTell
  • Jumblo
  • and many more.

Or you can DIY with the likes of Asterisk an open source framework providing all the tools anyone would need to spoof caller Ids and much more.

Favour for a Favour

Easy Common Average Severe

How this works: An Attacker (Pretexter) calls someone at the target organisation (often an employee). Then explains to them that something has just happened that will stop them from doing their work. Ideally something that the victim can not immediately verify. Attacker suggests that they may be able to fix the problem for the employee, but it'll be a big favour. Victim agrees and is very appreciative. Once the attacker has pretended to fix the employees issue, they get the victim to confirm that it is now working (of course it always was working). Victim confirms it's now working and is very appreciative. Now the victim essentially ows the attacker a favour. The attacker can use this favour that's essentially owed to them immediately or often more effectively the next day (next day seems more genuine).

These attacks are the easiest to carry out on:

  • new people
  • people with limited computer knowledge and skills, as they probably won't realise what value exists on the computer or network for the person that's just apparently helped them out

The New Employee

Easy Common Average Severe

New employees won't intuitively know a lot of people in the organisation yet. They won't yet understand the hierarchical relationships and processes. They won't be aware of the security policies and culture in force. They'll be as keen as can be to make good impressions with everyone they relate with.

We Have a Problem

Average Common Average Severe

An excellent way of gaining additional trust is to fix the problem that doesn't exist. Lead the victim to believe that there's a problem that will stop them from getting there work done in some way. Request a little information. Fix the problem that never existed. Victim verifies that there is no longer a problem. Request additional sensitive information. Using the fact that you just did a favour for the victim to elicit what you're after.

It's Just the Cleaner

Easy Common Easy Severe

Grab your self a cleaners uniform and you've got access to just about everything within an organisation. It really is that simple. Often when my wife was doing commercial cleaning and she walked into a room at 20:00 - 21:00 with a few developers left working away. They would sometimes be surprised because they hadn't been told that the cleaners were coming, let-a-lone, who they were. The response would usually go something like "Oh, it's just the cleaners". Why? Because they had their free pass... a cleaners uniform, maybe a broom or vacuum cleaner or mop.

Come On In Sir

Easy Common Easy Severe

Two effective ways at getting into a work premises.

  1. Mingle in with a crowd of people returning from a lunch break. Be prepared to drop some names of people that work there but are not in the current group. Yes, that means you have to do your home work and know their faces. You'll get through the locked front door 99% of the time.
  2. Wait in the car park until you see someone close to the front door (inside or outside) and carry a large heavy looking box toward the door. 99% of the time, they will open the door for you. Just make sure you have thought about all possible questions that may get fired at you and have well researched answers ready to respond with.

3. SSM Countermeasures

Phone calls

Difficult

Even the most technically and security focussed people can be played.

Focus on the low hanging fruit. Social Engineering attacks via phone calls is definitely one of the lowest. Using the output from the various risk rating and ranking of threats from 2 SSM Identify Risks will help you realise this.
Make sure that people being trusted are trustworthy. Test them. Most attacks target trusted people because they have something of value. Make sure the amount of value they have access to is in proportion to how trustworthy they actually are. Don't assume. Educate (train) and test employees. Make sure they are well compensated. Do what ever it takes to keep their levels of passion and engagement high. People with these qualities will be far more likely to succeed in recognising and warding off attacks.

Spoofing Caller Id

Average

Don't rely on caller Id. It's untrusted. I'm not aware of any way to successfully detect caller Id spoofing before the call is answered.

Favour for a Favour

Average

If someone you don't know does you a favour then asks for a favour. You're probably being played. Get suspicious. Start thinking hard about what they're actually asking for.

The New Employee

Average

All employees must be educated in that they should never reveal their passwords. It doesn't matter who to. If a password is asked for, suspicions should be instantly raised to finding out the identity of the requester, as they're obviously malicious or extremely ill-informed. This is often a good candidate to practise reverse social engineering on the requester, finding out as much about the person and what they're after as possible without raising suspicions that their disguise has been identified.

We Have a Problem

Average

Many of the social engineering attacks put a focus on a problem that doesn't exist, but sounds very real. If the pretend problem could stop the victim from getting their work done, that'll provide more leverage and more willingness on the part of the victim to give up sensitive data that they otherwise wouldn't.

It's Just the Cleaner

VeryEasy

  1. Think. Respect your workers. Provide them with the visibility as to who is allowed access to where and when.
  2. Train your workers
  3. Test them. Send some random in without telling your workers and see what happens. Adjust your training to suite

Come On In Sir

Average


All of these attacks require: Train -> Test -> Repeat

Creating an organisation wide single point of contact that can process all security related concerns will help to see when an attack is in progress, as in most cases, the attacker(s) will be making multiple attempts to pre-load and elicit sensitive information. Often from multiple targets. Emphasise that employees should contact that single point at even the slightest feeling of something being a bit suspicious.

If you took the people out of the security equation, there would be no insecurities. People are the source of (I'm fairly sure) all of the security issues we face today. So realistically, this is where we need to focus most of our attention. Education, establishing cultures of people that understand the issues, are prepared to and expect to be played and can and do react appropriately.

4. SSM Risks that Solution Causes

Often the modern thinking is that we can replace flawed people with technology. People are resilient and dynamic. They can spot a threat they've never seen before and defend against it. Computers can only defend against what they've been programmed to defend against. Technological defences are brittle. It's the role of technology to support humans to make good decisions.

Employees can get complacent with training, unless they are faced with very real simulations. Get creative, establish a base line training for all and additional training for areas of specialisation and extra trust.

5. SSM Costs and Trade-offs

An exercise for the reader. What are they?

Additional Resources

The following books have been influential for me and the above content should reflect that. They are very insightful and well worth the investment.

  • The Social Engineer's Playbook: A Practical Guide to Pretexting by Jeremiah Talamantes
  • Social Engineering: The Art of Human Hacking by Christopher Hadnagy
  • The Art Of Deception by Kevin Mitnick
  • Chapter 10 of Beyond Fear by Bruce Schneier
  • Gray Hat Hacking The Ethical Hacker's Handbook

10,000' view of Cloud and In-house Cloud Security

See VPS, as it has a lot of similarities due to the fact that in many cases your VPS may be on someone else's hardware and in their control.

1. SSM Asset Identification

Take results from higher level Asset Identification. Remove any that are not applicable. Add any newly discovered.

2. SSM Identify Risks

Go through same process as we did at the top level, but for your VPS(s).

The following is an excellent set of ten must-answer questions from DarkReading to throw at your CSP as part of your threat modelling before (or even after) you sign their service agreement.
Most of these questions were already part of my Cloud vs In-house talk at Saturn before I saw them. I'd recommend using these as a basis for identifying risks that may be important for you to consider. Then you should be well armed to come up with countermeasures.

Do You Keep a Signed Audit Trail of Which Users Performed What Actions When, Both Through Your UI & API?

"It's important to help protect against both mistaken and malicious actions when users know there is an audit trail, they will act with greater potential to detail, and also be dissuaded from using the platform as a vehicle for an attack. Having an audit trail is also helpful for troubleshooting purposes and root cause analysis."

Bernard Sanders, CTO, CloudBolt Software

What is My Role & Your Role in the Protection of My Data?

"Understanding that enterprises have to play a critical role in protecting their own data and how that data is accessed, even if leveraging a cloud provider, is critical for risk management. Most cloud providers will require a shared responsibility for security and enterprises cannot assume the provider is liable for data breaches."

Rehan Jalil, CEO, Elastica

Do You Encrypt All Data Transmissions, Including All Server-To-Server Data Transmissions, Within Data Centers?

"Security is only as strong as the weakest link. While it is very common to encrypt the traffic between the customer and the service provider in order to ensure integrity and confidentiality, it is less common for service providers to encrypt intra-server communications within the companies own perimeter. Too often attackers are able to exploit this type of weakness once a single breach in the perimeter has occurred."

Paul Hill, senior consultant, SystemExperts

What Access do You Provide to Logs?

"As simple as it sounds, access to logs should be one of the top concerns when evaluating providers. End users are not going to get the rich log information set that they would get from the server in their data center as they will get from a cloud provider and the organization must carefully consider what information they will and will not obtain from the provider. While some information may not be relevant to the organization, it is possible that other critical pieces might not be revealed and if necessary the organization should try to negotiate relevant log access early on."

Rob Ayoub, research director, NSS Labs

What is Your Termination or 'Exit Process' for Ensuring Successful Transition from your Services to an Alternative Offering?

"Let’s face it. Not all relationships can last forever. That said, companies need to review how to gracefully and effectively exit a relationship with a cloud provider. It’s important for organizations to have the following included in their contract with their cloud provider:

  • How the provider will assist with the transition, including providing the company’s data back to them or a third party in an effective manner.

  • What the provider’s destruction or electronic shredding policies are so the company can have evidence that its data is no longer resident on the provider’s systems and, therefore, not subject to attack or e-discovery.

  • That the provider has independent third parties that review and certify the efficacy of their exit procedures."

Renee Guttmann, vice president, Office of the CISO, Accuvant

Where do Your Servers, Processes, & Data Physically Reside?

"Although cloud computing is often promoted as a borderless construct, cloud providers must house all of your organization’s processes and data in real countries, which have varying legal requirements for data privacy and security. Be aware of the requirements of both your home country and the country where your assets will be hosted."

Stephen Ellis, manager, iSIGHT Partners

Who Can View Enterprise Data in the Cloud?

"Just like in an internal data center, there will be support staff who will maintain the cloud provider infrastructure. Understand which of these personnel can see your data. What internal controls are in place to prevent unauthorized viewing, copying or emailing of customer information?"

Danelle Au, vice president of strategy, Adallom

What is Your Service Level Agreement (SLA) for Uptime?

"Many providers offer a 99.9% uptime, which equates to nearly 45 minutes of unscheduled downtime per month. Even when the SLA is breached, a 'credit' issued to your account is only a percentage of the monthly fee - not anywhere near to the downtime cost to your business. Selecting a cloud provider that offers the right uptime guarantee is critical in finding the right solution for your specific company’s needs."

Nick Zeigler, senior cloud architect, All Covered, a division of Konica Minolta Business Solutions

Do you have ISO27001:2013 Certification? & if you do, What is Within its Scope?

"This question is aimed at finding out if a cloud provider has achieved a recognized information security standard and if their entire business is within the scope of the certification—in other words, their business systems and operations, and operational platforms, rather than just one or the other."

Orlando Scott-Cowley, cyber security specialist, Mimecast

Do You Allow Customers to Perform Scheduled Penetration Tests of Either the Production Environment or a Designated Testing Environment?

"Penetration testing is a common method used by companies to ensure their systems are well defended from attacks. Cloud service providers that allow customers to perform such testing are willing to be transparent about their security practices and also likely to be confident that their systems are well secured."

Paul Hill, senior consultant, SystemExperts

3. SSM Countermeasures

Once you have sprung the questions from above on your service provider, you will have a good set of answers that have feed into the process of Identifying Risks. Once you have defined the risks, the countermeasures will emerge

4. SSM Risks that Solution Causes

Are there any? If so what are they?

5. SSM Costs and Trade-offs

An exercise for the reader. What are they?

10,000' view of VPS Security

I usually advocate bringing VPS(s) in-house where you have control.

1. SSM Asset Identification

Take results from higher level Asset Identification. Remove any that are not applicable. Add any newly discovered.

2. SSM Identify Risks

Go through same process as we did at the top level, but for your VPS(s).

Forfeit Control thus Security

Average WideSpread Average Severe

In terms of security, unless your provider is Swiss, you give up so much when you forfeit your system(s) to an external provider. I cover this in my talk "Does Your Cloud Solution Look Like a Mushroom".

  • If you don't own your VPS(s), you will have very limited security, visibility and control over the infrastructure.
  • Limited (at best) visibility into any hardening process your CSP takes. Essentially you "Get what you're given".
  • Cloud and hosting providers are in many cases forced by governments and other agencies to give up your secrets. It's very common place now and you may not even know that it has happened. Swiss providers may be the exception here.
  • What control do you have that if you're data in the cloud has been compromised you actually know about it and can invoke your incident response team(s) and procedures?
  • Cloud and hosting providers are readily giving up your secrets to government organisations and the highest bidders. In many cases you won't know about it.
  • Your provider may go out of business and you may get little notice of this.
  • Providers are outsourcing their outsourced services to several providers deep. They don't even have visibility themselves. Control is lost.
  • > distribution = > attack surface. Where is your data? Where are your VM images running from? Further distributed on iSCSI targets? Where are the targets?
  • Your provider knows little (at best) about your domain, how you operate, or what you have running on their system(s). How are they supposed to protect you if they have no knowledge of your domain?

System Compromise

This is pretty much a blanket heading. It really needs to be broken down more.
Todo

3. SSM Countermeasures

Forfeit Control thus Security

Average WideSpread Average Severe

Bringing your VPS(s) in-house provides all the flexibility/power required to mitigate just about all the risks due to outsourcing to a cloud or hosting provider. Cloud offerings are often more expensive in monetary terms for medium to large environments.

Minimise Attack Surface by Granular Partitioning

Average

By creating many partitions and applying the least privileges necessary to each in order to be useful, you're making it difficult for an attacker to carry out many malicious activities that they would otherwise be able to. This is where you play with your /etc/fstab

This is a similar concept to tightly constraining input fields to only be able to accept structured data (names (alpha only) dates, social security numbers, zip codes, e-mail addresses, etc) rather than just leaving the input wide open to be able to enter any text.

Minimise Attack Surface by Installing Only what you Need

VeryEasy

This pretty much goes without saying I think, unless you're setting up a Windows server with "all the stuff" that you have no control over. Which is why I prefer UNIX based servers. I have all the control. If anything goes wrong, it's usually my own fault.

Review Password Strategies

Easy

Make sure passwords are encrypted with an algorithm that will stand up to the types of attacks you anticipate. Details here.

Disable Remote Root Logins

VeryEasy

There are a handful of files to check & modify for disabling root logins.

Harden SSH

VeryEasy

There are a bunch of things you can do to minimise SSH being used as an attack vector.
Use Key-pairs, Long pass-phrases. Appropriate changes to sshd_config file.
AllowUsers.
Specify Host(s).
Consider non default port below 1025 that only root can bind to in order to stop the sshd being swapped.

Disable Boot Options

VeryEasy

Just another attack vector that should be removed

Disable, Remove Services. Harden what's left

Easy

There are often a few services you can disable even on a bare bones Debian install and some that are just easier to remove. Then go through the process of hardening what's left. Make sure you test before and after each service you attack. Watch the port being open/closed, etc.

Schedule Backups

Easy

and make sure you can restore from them. Yes it's extra work, but work that will be invaluable if those backups don't restore.
Also consider setting up automatic updates.

Host Intrusion Detection Systems (HIDS)

Average

I recently performed an in-depth evaluation of a couple of HIDS. The choice of which candidates to take into the second round came from my initial evaluation.

Logging and Alerting

Average

I recently performed an in-depth evaluation of a small collection of logging and alerting offerings. The choice of which candidates to take into the second round came from my initial evaluation.

It's very important to make sure you have reliable and all-encompassing logging to an off-site location. This way attackers will have to also compromise that location in order to effectively cover their tracks.

Monitoring

Average

I recently performed an in-depth evaluation of a collection of tools that one of their responsibilities was monitoring and performing actions on your processes and applications.

  1. Supervisor evaluation
  2. Monit evaluation
  3. Passenger evaluation

Host Firewall

Easy

This is one of the last things you should look at. In fact, it's not really needed if you've taking the time to remove unnecessary services and harden what's left. If you use a host firewall keep your set of rules to a minimum to reduce confusion and increase legibility. Maintain both ingress & egress.

4. SSM Risks that Solution Causes

Are there any? If so what are they?

  • Just beware that if you're intending to break the infrastructure or even what's running on your VPS(s) if they're hosted on someone else's infrastructure, that you make sure you have all the tests you intend to carry out documented including what could possibly go wrong, accepted and signed by your provider. Good luck with this. That's why I usually recommend self hosting.
  • Keep in mind: that if you don't break your system(s), someone else will.
  • Possible time constraints: It takes time to find skilled workers, gain expertise, set-up and configure.
  • Many of the points I've raised around VPS hardening require maintenance.

5. SSM Costs and Trade-offs

An exercise for the reader. What are they?

10,000' view of Network Security

1. SSM Asset Identification

Take results from higher level Asset Identification. Remove any that are not applicable. Add any newly discovered.

2. SSM Identify Risks

Go through same process as we did at the top level, but for the network.

Network risks are obviously huge. I'm probably not even going to scratch the surface here at this stage.

Spoofing

Spoofing on a network is the act of an entity (often malicious(Mallory), but not necessarily) successfully masquerading/impersonating another (Bob) in order to receive information from Alice (sometimes via Eve) that should then reach Bob.

The following are some of the different types of network spoofing

IP

Easy Common Average Severe

Setting the IP address in your header to the victims IP address.

This is where a sending node will spoof its public IP address (not actually change its IP address) (by forging the header) to look like someone else's. When the message is received and a reply crafted, the entity creating the reply will look up its ARP table and send the reply to the impersonated entity because the MAC address is still associated with the IP address of the message it received. This sort of play is commonly used in Denial of Service (DoS) attacks, because the attacker does not need or want the response.

In a Distributed DoS (D-DoS) Often the attacker will impersonate the target (often a router or some server it want to be brought to its knees) and broadcast messages. The nodes that receive these messages consult their ARP tables looking up the spoofed IP address and find the targets associated MAC address and reply to it. This way the replies will be sourced from many nodes. Thus swamping the targets network interface.
Many load testing tools also use this technique to stress a server or application.

ARP (Address Resolution Protocol)

Easy Common Average Severe

Telling your target that the MAC address it associates with a particular legitimate node (by way of IP address) is now your (the attackers/MitM) MAC address.

Taking the IP spoofing attack further. The MitM sends out ARP replies across the LAN to the target, telling it that the legitimate MAC address that the target associates with the MitM box has now changed to say the routers IP address. This way when the target wants to send a message to say the router, it looks up its ARP table for the routers IP address in order to find its MAC address and now gets the MitM MAC address for the routers IP address, thus the targets ARP cache is said to be poisoned with the MitM MAC address. The target goes ahead and sends its messages to the MitM box which can do what ever it likes with the data. Choose to drop the message or to forward it on to the router in its original or altered state.
This attack only works on a LAN.
The attack is often used as a component of larger attacks, harvesting credentials, cookies, CSRF tokens, hijacking. Even using TLS (in many cases TLS can be downgraded).

Hands On Hack

DNS

Difficult UnCommon Average Moderate

Affects any domain name lookup. That includes email. This type of attack could allow an intermediary to intercept and read all company emails for example. Completely destroying any competitive advantage. The victim may never know it's happened.
DNS spoofing refers to an end goal rather than a specific type of attack. There are many ways to spoof a name server.

  • Compromise the name server itself potentially through it's own vulnerabilities (Kaminsky bug for example)
  • Poison the cache of the name server
  • Poison the cache of an upstream name server and wait for the downstream propagation
  • MitM attack. A good example of this is:
    • cloning a website you hope your victim will visit
    • offering a free wifi hot-spot attached to your gateway with DNS server provided. Your DNS server provides your cloned website IP address. You may still have to deal with X.509 certificates though, unless the website enforces TLS across the entire site, which is definitely my recommendation. If not, and the potential victim already has the websites certificate they are wanting to visit in their browser, then you'll have to hope your victim will click through the warning or work out a TLS downgrade which is going to be harder.

dnschef is a flexible spoofing tool. Would be interesting to test on the likes of Arpon and Unbound.

Referrer

Easy Common Average Moderate

This comes under the OWASP Top 10 A7 Missing Function Level Access Control

Often websites will allow access to certain resources so long as the request was referred from a specific page defined by the referer header.
The referrer (spelled referer) field in HTTP requests can be intercepted and modified, so it's not a good idea to use it for authentication or authorisation.

Hands On Hack

E-Mail Address

Easy Widespread Average Severe

The act of creating and sending an email with a forged sender address. This is useful for spam campaigns sending large numbers of email and for social engineers often sending small numbers of email. The headers can be specified easily on the command line. The tools used essentially modify the headers: From and Return-Path.

Most people just assume that an email they've received came from the address it appears to be sent from. The Email headers are very easy to tamper with. Often other types of spoofing attacks are necessary in order to have the From and Return-Path set to an address that a victim recognises and trust rather than the attackers address or some other obviously obscure address.

There are also on-line services that allow the sending of email and specifying any from address.

Often the sender of a spoofed email will use a from address that you recognise in hope that you'll click on a link within the email thus satisfying their phish.

Website

Difficult Common Average Severe

An attacker can clone a legitimate website (with the likes of the Social Engineering Kit (SET)) and through social engineering, phishing, email spoofing or any other number of tricks coerce a victim to browse the spoofed website. Once on the spoofed website, the attacker can harvest credentials or carry out many other types of attacks against the non-suspecting user.

Often a website is cloned that the victim visits regularly, which can even remove the need for social engineering, phishing, email spoofing. The victim visits the attackers cloned website due to ARP or DNS spoofing. The attacker can do any number of things at this point. Simply harvest credentials or launch many different types of attacks. For example Subterfuge to run a plethora of attacks against the victims browser through the likes of the Metasploit Browser AutoPwn module. If >0 attacks are successful, the attacker will usually get a remote command shell to the victims system. Then simply forward them onto the legitimate website without them even being aware of the attack.

Hands On Hack

Wrongfully Trusting the Loading of Untrusted Web Resources

Average VeryWidespread Easy Moderate

By default, the browser allows all resources from all locations to be loaded. What would happen if one of those servers was compromised or an attacker was tampering with the payload potentially changing what was expected for something malicious to be executed once loaded?

Hands On Hack

TLS Downgrade

Average Common Average Severe

When ever a user browses to a website, an attacker can intercept the request before the TLS handshake is made and redirect the user to the same website but without the TLS.

This is a danger for all websites that don't enforce TLS for every page. For example many websites are run over plain HTTP until the user wants to log-in. At which point the browser issues a request to an HTTPS resource (that's listed on an unencrypted page). These requests can easily be intercepted and downgraded to a plain HTTP request.

Firewall/Router

Routing Configurations Todo

3. SSM Countermeasures

Spoofing

IP

Difficult

Filter incoming packets (ingress) that appear to come from an internal IP address at your perimeter.
Filter outgoing packets (egress) that appear to originate from an invalid local IP address.
Not relying on IP source address's for authentication (AKA trust relationships). I've seen this on quite a few occasions when I was younger and it didn't feel right, but I couldn't put my finger on why? Now it's obvious.

ARP (Address Resolution Protocol)

Average

Use spoofing detection software.
As ARP poisoning is quite noisy. The attacker continually sends ARP packets, IDS can detect and flag it. Then an IPS can deal with it.

Tools such as free and open source ArpON (ARP handler inspection) do the whole job plus a lot more.
There's also ArpWatch and others.

Thoughts on mitigations

DNS

Average

Many cache poisoning attacks can be prevented on DNS servers by being less trusting of the information passed to them by other DNS servers, and ignoring any DNS records passed back which are not directly relevant to the query.

DNS Security Extensions does the following for us. You'll probably need to configure it though on your name server(s). I did.

  • DNS cache poisoning
  • Origin authentication of DNS data
  • Data integrity
  • Authenticated denial of existence

Make sure your Name Server supports DNSSEC.

Referrer

Easy

Deny all access by default. Require explicit grants to specific roles for access to every function. Implement checks in the controller and possibly the business logic also (defence in depth). Never trust the fact that certain resources appear to be hidden so a user wont be able to access them.

Check the OWASP Failure to Restrict URL Access for countermeasures and the Guide to Authorisation.

EMail Address

Difficult

Spoofing of Email is hard to trace and stop.

Key-pair encryption helps somewhat. The headers can still be spoofed, but the message can not, thus providing secrecy and authenticity:

  • GPG/PGP (uses "web of trust" for key-pairs)
    Application Layer
    Used to encrypt an email message body, any file for that matter and also signing.
    Email headers not encrypted

  • S/MIME (uses Certificate Authorities (CA's)(Can be in-house) TLS using PKI)
    Application Layer
    Used to encrypt an email message body and also signing
    Email headers not encrypted

The way the industry is going currently it's looking like the above (same) key-pair encryption will probably be replaced with Forward Secrecy who's key changes on each exchange.

GPG/PGP and S/MIME are similar concepts. Both allow the consumer to encrypt things inside an email.
See my detailed post on GPG/PGP here for more details.

I've noticed some confusion surrounding S/MIME vs TLS. TLS works at the transport & session layer as opposed to S/MIME at the Application Layer. The only similarity I see is that they both use CA's.

  • Adjust your spam filters
  • Read your message headers and trace IP addresses, although any decent self respecting spammer or social engineer is going to be using proxies.
  • Don't click links or execute files from unsolicited emails even if the email appears to be from someone you know. It may not be.
  • Make sure your mail provider is using Domain-based Message Authentication, Reporting and Conformance (DMARC)
    • Sender Policy Framework (SPF)
    • DomainKeys Identified Mail (DKIM)

Website

Average

There's nothing to stop someone cloning and hosting a website. The vital part to getting someone to visit an attackers illegitimate website is to either social engineer them to visit it, or just clone a website that you know they are likely to visit. An Intranet at your work place for example. Then you will need to carry out ARP and/or DNS spoofing. Again tools such as free and open source ArpON (ARP handler inspection) cover website spoofing and a lot more.

Wrongfully Trusting the Loading of Untrusted Web Resources

  • Escaping all untrusted data based on it's context (where and what it is)
  • White-list
  • Constrain to types where possibly
  • Constrain max / min lengths.
  • Basically think in terms of least privilege

OWASP Top 10 A3 Cross Site Scripting (XSS)

Content Security Policy (CSP)

Average

By using CSP, we're providing the browser with a white-list of the types of resources and from where, that we allow to be loaded.
We do this by specifying particular response headers (more specifically directives).

Names removed to save embarrassment. Sadly most banks don't take their web security very seriously.

curl --head https://reputable.kiwi.bank.co.nz/

Content-Security-Policy: default-src 'self' secure.reputable.kiwi.bank.co.nz;
connect-src 'self' secure.reputable.kiwi.bank.co.nz;
frame-src 'self' secure.reputable.kiwi.bank.co.nz player.vimeo.com;
img-src 'self' secure.reputable.kiwi.bank.co.nz *.g.doubleclick.net www.google.com www.google.co.nz www.google-analytics.com seal.entrust.net;
object-src 'self' secure.reputable.kiwi.bank.co.nz seal.entrust.net;
# In either case, authors SHOULD NOT include either 'unsafe-inline' or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself
# unsafe-eval should go without saying
script-src 'self' 'unsafe-eval' 'unsafe-inline' secure.reputable.kiwi.bank.co.nz seal.entrust.net www.googletagmanager.com www.googleadservices.com www.google-analytics.com;
style-src 'self' 'unsafe-inline' secure.reputable.kiwi.bank.co.nz seal.entrust.net;

Of course this is only as good as a clients connection is trusted. If the connection is not over TLS, then there is no real safety that the headers can't be changed. If the connection is over TLS, but the connection is intercepted before the TLS hand-shake, the same lack of trust applies. See the section on TLS Downgrade for more information.
Not to be confused with Cross Origin Resource Sharing (CORS). CORS instructs the browser to over-ride the "same origin policy" thus allowing AJAX requests to be made to header specified alternative domains. For example: web site a allows restricted resources on its web page to be requested from another domain outside the domain from which the resource originated. Thus specifically knowing and allowing specific other domains access to its resources.

  • Slide Deck from Francois Marier
  • Another Slide Deck from Francois Marier. Also covering HTTP Strict Transport Security (HSTS)
  • Easy Reading: OWASP
  • OWASP CSP Cheat Sheet which also lists which directives are new in version 2
  • MDN easily digestible help on using CSP
  • Easy, but more in-depth:
    • W3C specification 2. It is the specification after all. Not sure about browser support here yet.
      Todo: write script that performs feature detection of version 2 of the specification.
    • W3C specification 1.1. Most browsers currently support this version. IE 11 has partial support.

Sub-resource Integrity (SRI)

Easy

Provides the browser with the ability to verify that fetched resources (the actual content) haven't been tampered with, potentially swapping the expected resource or modifying it for a malicious resource, no matter where it comes from.

How it plays out:
Requested resources also have an attribute integrity with the cryptographic hash of the expected resource. The browser checks the actual hash against the expected hash. If they don't match the requested resource will be blocked.

<script src="https://example.com/example-framework.js"
    integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg="
    crossorigin="anonymous"></script>

This is of course only useful for content that changes rarely or is under your control. Scripts that are dynamically generated and out of your control are not really a good fit for SRI. If they're dynamically generated as part of your build, then you can also embed the hash into the requesting resource as part of your build process. Currently script and link tags are supported. Future versions of the specification are likely to expand this coverage to other tags.

SRI is also useful for applying the hash of the likes of minified, concatenated and compressed resources to the name of them for invalidating browser cache.

SRI can be used right now. Only the latest browsers are currently supporting SRI, but the extra attributes are simply ignored by browsers that don't currently provide support.

Tools such as openssl and the standard sha[256|512]sum programmes normally supplied with your operating system will do the job. The hash value provided needs to be base64 encoded.

TLS Downgrade

HTTP Strict Transport Security (HSTS)

Easy

Trust the browser to do something to stop these downgrades.

curl --head https://reputable.kiwi.bank.co.nz/

Strict-Transport-Security: max-age=31536000

By using the HSTS header, you're telling the browser that your website should never be reached over plain HTTP.
There is however still a problem with this. The very first request for the websites page. At this point the browser has no idea about HSTS because it still hasn't fetched that first page that will come with the header. Once the browser does receive the header, if it does, it records this information against the domain.
Welcome to HSTS Preload

Online Certificate Status Protocol (OCSP) is very similar to HSTS, but at the X.509 certificate level.

HTTP Strict Transport Security (HSTS) Preload

Easy

This includes a list that browsers have with any domains that have been submitted. When a use requests one of the pages from a domain on the browsers HSTS preload list, the browser will always initiate all requests to that domain over TLS.

In order to have your domain added to the browsers preload list, submit it here.

OCSP Must-Staple is very similar to HSTS Preload, but at the X.509 certificate level.

Firewall/Router

I don't trust commercial proprietary routers. I've seen too many vulnerabilities in them to take them seriously for any network I have control of. Yes open source hardware and software routers can and do have vulnerabilities, but they can be patched. There are a few good choices here. Some of which also come with enterprise support if you want it. This means the software and the hardware, if you choose to obtain the hardware as well is open to inspection. The vendor also supplies regular firmware updates which is crucial for there to be any hope of having a system that in some way resembles a device that places a priority on your networks security.

Most closed routers suffer from the same problems I illustrate on my blog. They have active unsecured services that have little to nothing to do with routing and in many cases, you can not Disable, Remove, or Harden them.

Network Intrusion Detection Systems (NIDS)

Similar to HIDS but acting as a network spy with its network interface (NIC) in promiscuous mode, capturing all traffic crossing the specific network segment that the NIDS is on.

As HIDS, NIDS also operate with signatures.

  1. String signatures look like known attack strings or sub-strings. "For example, such a string signature in UNIX can be "cat "+ +" > /.rhosts" , which if executed, can cause the system to become extremely vulnerable to network attack."
  2. Port: "Port signatures commonly probes for the connection setup attempts to well known, and frequently attacked ports. Obvious examples include telnet (TCP port 23), FTP (TCP port 21/20), SUNRPC (TCP/UDP port 111), and IMAP (TCP port 143). If these ports aren't being used by the site at a point in time, then the incoming packets directed to these ports are considered suspicious."
  3. Header condition: "Header signatures are designed to watch for dangerous or illegitimate combinations in packet headers fields. The most famous example is Winnuke, in which a packet's port field is NetBIOS port and one of the Urgent pointer, or Out Of Band pointer is set. In earlier version of Windows, this resulted in the "blue screen of death". Another well known such header signature is a TCP packet header in which both the SYN and FIN flags are set. This signifies that the requestor is attempting to start and stop a connection simultaneously."

Quotes from the excellent Survey of Current Network Intrusion Detection Techniques

Some NIDS go further to not only detect but prevent. They are known as Network Intrusion Prevention Systems NIPS.

It's a good idea to have both Host and Network IDS/IPS in place at a minimum. I personally like to have more than one tool doing the same job but with different areas of strength covering the weaker areas of its sibling. An example of this is with HIDS. Having one HIDS on the system it's protecting and another somewhere else on the network, or even on another network completely, looking into the host and performing its checks. This makes discoverability difficult for an attacker.

Vulnerability Scanners

For infrastructure scanning use OpenVAS which is a free fork from Nessus after the tool went proprietary in 2005. I wrote about it here.

Todo document others.

4. SSM Risks that Solution Causes

Are there any? If so what are they?

Wrongfully Trusting the Loading of Untrusted Web Resources

Content Security Policy (CSP)

Trusting the (all supported) browser(s) to do the right thing.
Don't. Remember defence in depth. Expect each layer to fail, but do your best to make sure it doesn't. Check the likes of the OWASP How Do I Prevent Cross-Site Scripting (XSS) for taking the responsibility yourself rather than deferring to trust the clients browser.

Take care in making sure all requests are to HTTPS URLs. You could also automate this as part of your linting procedure or on a pre-commit hook on source control.

Make sure your web server only ever responds over HTTPS, including the very first response.

Sub-resource Integrity (SRI)

Similar to the above with trusting the browser to support the SRI header. All requests should be made over HTTPS. The server should not respond to any requests for unencrypted data.

Take care in making sure all requests are to HTTPS URLs. You could also automate this as part of your linting procedure on a pre-commit hook or source control.

Make sure your web server only ever responds over HTTPS, including the very first response.

TLS Downgrade

HTTP Strict Transport Security (HSTS)

Unless the browsers know about your domain and have it added to their HSTS Preload list, then the connection is still not safe.

Make sure your web server only ever responds over HTTPS, including the very first response.

HTTP Strict Transport Security (HSTS) Preload

Again your trusting the browser.

5. SSM Costs and Trade-offs

An exercise for the reader. What are they?

Wireless

A really large can of worms

Todo

10,000' view of Web Application Security

Development Practices

Let's look at some of the practices we can use as developers to lift the level of security within our software.

Architecture

There are no architects in Scrum. Just Developers. Some of those developers have architect qualities. They like to step back often to see the bigger picture and understand the interactions between the components and the people using the software. Including every aspect to do with the end product, the people intending to use it and the risks.

Agile architecture does a little design up front in collaboration with the team and everyone that has a vested interest. Agile architecture is not siloed, because it's part of development, just as analysing requirements and testing. It's all done in parallel.

So, we don't really separate the discipline of architecture from a software developer that excels at doing what a traditional architect does as well as engineering.


Security Test-Driven Development (STDD)

red green refactor

There are a couple of aspects I'd like to focus on here. You can simply continue to use your existing automated test suites and frameworks. All you have to do is:

  1. Add a security focused test API into the mix of your existing automated acceptance test suites.
    You're chosen (language specific) BDD framework of choice, putting legs to your test conditions with automatable "Given, When, Thens".
  2. Add security focused BDD/TDD/ATDD tests. This is the same amount of work as any other automated TDD, but it has the huge benefit of bringing the finding of security faults from where it's very expensive to fix:

    Costs Of Change

    to where it's the cheapest possible place to fix:

    Cost Of Change with STDD


  1. Continuing No. 1 from above: OWASP ZAP (which also comes pre-installed on Kali Linux ) is a particularly useful tool for SBDD and regression testing. Because it not only provides a manual tool similar to the likes of Burp Suite + with many other features. ZAP also has the ability to run as a HTTP proxy:

    1. You can run ZAP manually then through the menu Tools -> Options... -> API turn the HTTP API on
    2. Run ZAP from the command line using the -daemon flag
    owasp-zap -daemon

    You can then access the API like this:

    curl http://localhost:8080 # Providing ZAP is listening on port 8080

    This allows us to within our Behavioural, Acceptance tests, send requests programmatically directly to the ZAP HTTP API to do what ever we could do manually with the tool against the System Under Test (SUT). You can of course use Selenium 2 (WebDriver) also to drive browser tests and in parallel. I discussed this in "Automating Specificatioin by Example".

    The ZAP API can be accessed directly or by any of the following client implementations:

    • Node.JS (by way of zaproxy)
    • Python
    • PHP
    • Ruby
    • .Net write-up, source. It's easy to see how the API is started and used here.
      There's also the OWASP Secure TDD Project. A .Net solution. This project appears to either be abandoned or just very low activity. Feel free to offer to help though if you're a .Net developer. I'm not sure I agree with one of the opening statements: "they need to cover all tests prior development". The approach that I'd take would be to write some specification (test), execute it, (red) -> Write the smallest amount of code possible to make it pass (green) -> Add to the specification (test)(refactor). As you can see that's your red->green->refactor loop, with the smallest amount possible for each iteration.
    • Java. A couple of client projects useful for seeing how to use the ZAP API: zap-webdriver, bdd-security

    For getting started with OWASP ZAPs API chcek the

  2. Continuing No. 2 from above: This is adding another aspect to your existing TDD/BDD thought process. Instead of the business waiting until go-live before contracting the experts to beat up your system. Then tell you your security sucks. We take a proactive approach and move a lot of the effort traditionally performed at go-live up front, where you yourself as the developer can test and fix. Thus saving embarrassment and the business a lot of money.
    BSIMM has some good guidance on security testing

What's so good about STDD and SBDD, is that it roles up Specifications, Design, Implementation and Verification all into one process. Thus working toward delivering each increment that's truly "Done". Driving development with tests is not about testing right? It's about creating code that's testable. Testable code is inherently well designed and gives us the ability to reason about the state at any given time.
OpenSSL Heartbleed and Apples Goto Fail could have been prevented if (S)TDD was used. Check out Mike Bland's excellent study and POC.


Hand-crafted Penetration Testing

Sometimes known as "gorilla testing".

As previously discussed, this can be costly when performed late in a projects life cycle, so by automating as much as possible, including high level scans which help to identify starting points to attack, it leaves the developers to do what they do best...

Get creative.

There is no reason why developers can not take a good chunk of the manual penetration testing effort on as part of their daily development practices. In fact in most teams I've lead, this has been exactly how we've worked. The gorilla testing needs to be performed in parallel with the PBIs in the Scrum Backlog as developers pull them into Work I Progress (WIP).

Some developers gravitate toward security more than others, so it's important to have at least a none zero number of developers with a security focus within each team to:

  1. take the lead on the security front
  2. mentor and pass on their knowledge and passion to others

BSIMM againg has some good guidance on hands on penetration testing.


Code Review

If we can't get the simple things right like Coding standards and conventions to help remove some of the "wild west" attitudes and behaviours, then how will we ever get the complicated things right? The whole team needs to abide by the standards, conventions and guidelines.

Callback Hell Alternatives for example.

Manual and Automated.

Check out the BSIMM Code Review for some good ideas.

Linting, Static Analysis

Start with the likes of JSHint. There are lots of other good tooling options.

Techniques and tools to assist with automating

Dynamic Analysis

Tooling is still immature here. We've got a way to go, but lets start getting our feet wet.


Techniques for Asserting Discipline

JavaScript is an inherently flexible and undisciplined language. This quality is a double edged sword. It provides us with extreme power and also allows us to slaughter ourselves. Discipline is very much needed in order to stay safe and be able to reason about our applications as they grow larger.

I've been involved in many JavaScript project rescue missions where a development team can no longer understand what the monster they have created is doing, what state it is in and why? In almost all occasions, the developers on the team do not have a deep understanding of the language and often of any language. Because of this I always try and push the fact that JavaScript developers must do everything they can to understand the language. In most cases this means taking their learning home and getting intimate with JavaScripts beauty.

Because of the distinct lack of discipline within JavaScript (unlike most other languages) I try and bring as much understanding around techniques that can help impose the extra rigour where and when it's needed. The beautiful thing about JavaScript is that when you really need to do something unconventional, you can, but I like to weigh up the trade-offs of either approach.

Static Type Checking

In JavaScript we need as much help as we can to fail fast. Static type checking gives us this. It also feels like the step before DbC.

  • flow looks to be a good option. Providing consumers with the option of introducing type checking progressivly and/or to certain parts that make the most sense. Or rather missing parts that require the extra flexibility.
Design by Contract (DbC)

Enforcing preconditions, postconditions and invariants in our routines. That's right, we can even employ this design principle in JavaScript. I wrote about DbC in a previous post in regards to usage in .Net.
In JavaScript, I believe the DbC principle is even more important as part of adding discipline and keeping us on the straight and narrow. I believe DbC is the principle that helps us achieve the Liskov Substitution Principle, which is the 'L' in the SOLID design mnemonic. These are the offerings I've noticed that provide support:

  1. ristretto-js
  2. contract-js on NPM
  3. contractual on NPM

In many cases you can implement your cross cutting code contracts using AOP. This gets it out of your code, so that it's not in your face.

1. SSM Asset Identification

Take results from higher level Asset Identification. Remove any that are not applicable. Add any newly discovered.

2. SSM Identify Risks

Go through same process as we did at the top level, but for Web Application.

This slide was from a talk I did at OWASP NZ Day 2013. The top 10 vulnerabilities don't change a lot


OWASP Top 10 2013


They were actually very similar 10 years ago.

The unchangeable vulnerabilities are:

  • No. 1 Injection (and the easiest to fix)
  • No. 2 Broken Authentication and Session Management
  • No. 3 XSS
  • No. 4 Insecure Direct Object References
  • No. 5 Security Misconfiguration
  • No. 8 Frameworks are helping with CSRF
  • No. 9 is new, because we’re now consuming a lot more packages without vetting them.


Some Things Dont Change


Lack of Input Sanitisation

Easy Common Average Severe

Buffer Overflows

Todo

Cross-Site Scripting (XSS)

Todo

SQLi

Hands On Hack

One of the simplest and quickest vulnerabilities to fix, yet it's still top of the hit lists.
Lets hammer this home some more.

Command Injection

Hands On Hack

LDAP Injection

Todo

XPath Injection

Todo

XQuery Injection

Todo

XSLT Injection

Todo

XML Injection

Todo

Lack of Authentication

Todo
Todo
...

Cryptography on the Client (AKA Untrusted Crypto)

Consuming Free and Open Source

Average WideSpread Difficult Moderate

This is where A9 (Using Components with Known Vulnerabilities) of the 2013 OWASP Top 10 comes in.

We are consuming far more free and open source libraries than we have ever before. Much of the code we're pulling into out projects is never intentionally used, but is still adding surface area for attack. Much of it:

  • Is not tested (for what it should do and what it shouldn't do)
  • Is not reviewed evaluated
  • Is created by amateurs that could and do include vulnerabilities
  • Does not undergo the same requirement analysis, defining the scope, acceptance criteria, test conditions and sign off by a development team and product owner.

Many vulnerabilities can hide in these external dependencies. It's not just one attack vector anymore, it provides the opportunity for many vulnerabilities to be sitting waiting to be exploited. If you don't find and deal with them, I can assure you, someone else will.

See Justin Searls talk on consuming all the open source.

3. SSM Countermeasures

Lack of Input Sanitisation

Average

  • All user input should be escaped
  • Ideally user input should conform to white lists
  • Database accounts (in fact all accounts) should use least privilege
  • I cover input sanitisation here
  • Well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern

Buffer Overflows

Todo

Cross-Site Scripting (XSS)

Todo

SQLi

There are a few options here:

Command Injection

On top of the points mentioned above under Lack of Input Sanitisation This article is quite good.

LDAP Injection

Todo

XPath Injection

Todo

XQuery Injection

Todo

XSLT Injection

Todo

XML Injection

Todo

Lack of Authentication

Todo
Todo
...

Cryptography on the Client (AKA Untrusted Crypto)

Todo

Consuming Free and Open Source

Easy

Dibbe Edwards discusses some excellent initiatives on how they do it at IBM. I'll attempt to paraphrase some of them here:

  • Implement process and governance around which open source libraries you can use
  • Legal review: checking licenses
  • Scanning the code for vulnerabilities, manual and automated code review
  • Maintain a list containing all the libraries that have been approved for use.
    If not on the list, make request and it should go through the same process.
  • Once the libraries are in your product they should become as part of your own code so that they get the same rigour over them as any of your other code written in-house.
  • There needs to be automated process that runs over the code base to check that nothing that's not on the approved list is included.

There's an excellent paper by the SANS Institute on Security Concerns in Using Open Source Software for Enterprise Requirements that is well worth a read. It confirms what the likes of IBM are doing in regards to their consumption of free and open source libraries

For NodeJS developers: Keep your eye on the nodesecurity advisories

Leverage RetireJS to help you work out JavaScript libraries with known vulnerabilities. RetireJS has:

  1. A command line scanner. Excellent for builds. Include it in one of your build definitions and let it do the work for you.
  2. A Chrome extension
  3. A Grunt plugin
  4. Burp and OWASP ZAP plugin

Test your web site with the RetireJS online tool

For .Net developers, there is the likes of OWASP SafeNuGet

Web Application Firewall (WAF)

WAFs are similar to Intrusion Prevention Systems (IPS) except they operate at the Application Layer(HTTP), Layer 7 of the OSI model. So they understand the concerns of your web application at a technical level. WAFs protect your application against the likes of XSS, CSRF, SQLi, Local File Inclusion (LFI), session hijacking, invalid requests (requests to things that don't exist (think 404)). WAFs sit in-line between a gateway and the web application. They run as a proxy. Either on the physical web server or on another network node, but only the traffic directed to the web application is inspected, where as an IDS/IPS inspects all network traffic passed through it's interfaces. WAFs use signatures that look like specific vulnerabilities to compare the network traffic targeting the web application and apply the associated rule(s) when matches are detected. Although not only limited to dealing with known signatures, some WAFs can detect and prevent attacks they haven't seen before like responses containing larger than specified payloads.

  1. Fusker. Not sure if this is still actively maintained. At this point, there hasn't been any recent commits for about three years, but it does look like the best offering we have at this stage for NodeJS. So if your looking to help a security project out...
  2. express-waf has recent commits, but there is only a single developer working on it when I checked.
  3. AppSensor brings detection -> prevention to your domain level.
    Most applications today just take attacks & fall over.
    I've heard so many times we want our applications to fail securely when they get bad input.
    We don't want our applications being bullied and failing securely.
    We want them to not fail at all in production, but rather defend themselves.

    The project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into your applications. Providing attack awareness baked in, with real-time defences.

    AppSensor provides > 50 (signature based) detection points. Provides guidance on how to respond once attack identified.
    Possible actions include: logging out the user, locking the account or notifying an administrator, more than a dozen response actions are described.

4. SSM Risks that Solution Causes

Are there any? If so what are they?

5. SSM Costs and Trade-offs

An exercise for the reader. What are they?

Additional Resources

Attributions

The 30,000' View

Vulnerability advisories
kitploit.com did a small explanation of using the Exploit Database from Offensive Security

Mobile

Sells cell phone tracking systems to both corporations and governments worldwide. Bruce Schneier: Data and Goliath: Introduction

Locate. Track. Manipulate
http://www.washingtonpost.com/business/technology/for-sale-systems-that-can-secretly-track-where-cellphone-users-go-around-the-globe/2014/08/24/f0700e8a-f003-11e3-bf76-447a5df6411f_story.html

SkyLock not only finds people
http://apps.washingtonpost.com/g/page/business/skylock-product-description-2013/1276/

UK company Cobham sells a system that allows someone to send a "blind" call to a phone. Bruce Schneier: Data and Goliath: Introduction

The blind call forces the phone to transmit on a certain frequency Bruce Schneier: Data and Goliath: Introduction. Also blog posted.

Infiltrator
The global real-time tracking system. Also discussed in Bruce Schneier: Data and Goliath: Introduction. Bruce Schneier's blog post and the Washington Post. The website also claims: "It is a strategic solution that infiltrates and is undetected and unknown by the network, carrier, or the target."

Many of the applications installed on our phones are collecting your personal information

Locate mobile phones using SS7
Initial findings from Bruce Schneier: Data and Goliath: Introduction. Other resources found: Tobias Engel's presentation at the 25th Chaos Communication Congress
Tobias Engel's slide-deck
Wikipedia entry for Signalling System No. 7
Tobias Engel's video of his presentation
Nicholas Skiller's implementation of Tobias Engel's research

Many offerings available to allow people to spy on other individuals activities and location in regards to mobile phones.
News story discussed in Bruce Schneie: Data and Goliath: Introduction. Along with hellospy Also reported on by Craig Timberg and Matt Zapotosky.

Use location data to track people
Bruce Schneier: Data and Goliath: Introduction: USA National Security Agency (NSA) and its UK counterpart, Government Communications Headquarters (GCHQ), use location data to track people.
http://www.washingtonpost.com/world/national-security/nsa-tracking-cellphone-locations-worldwide-snowden-documents-show/2013/12/04/5492873a-5cf2-11e3-bc56-c6ca94801fac_story.html
http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/new-documents-show-how-the-nsa-infers-relationships-based-on-mobile-location-data