A Security Strategy for the New Normal

Light at the end of the tunnel   During the ongoing COVID-19 outbreak many security professionals have by necessity been operating tactically & in response mode, trying to identify and mitigate the security risks of organisations that have had to move rapidly to remote working. It is right that they do, as the risks are clear & stark, for example NASA’s Security Operations Centre has observed:
    • A doubling of email phishing attempts
    • An exponential increase in malware attacks
    • A doubling of NASA systems trying to access malicious internet sites
This is unsurprising, bad actors since the beginning of time have always exploited opportunities, and COVID-19 related remote working has created several:
    • Employees working on & saving company data on less secure home networks and home computers which are often shared with other family members
    • Lack of VPN licences or VPN bandwidth issues meaning increased insecure network access from untrusted machines
    • Employees being asked to use unfamiliar & hastily configured tools for conferencing, remote access, or sharing information
    • Simple process changes such as authorisation of invoices remotely being ripe for business email compromise where bad actors convincingly & often extremely successfully, impersonate senior executives and trick workers into sending sums of money into their account
Looking to the future, whilst fighting fires is never easy, now is the time to think about what a security strategy will look like in the “new normal” and the danger if security professionals are not able to influence wider organisational thinking at this time. So, what will the “new normal” look like? Well, it seems clear that some degree of social distancing is going to remain in place for the foreseeable future, and this is going to have a major impact on travel, and the way traditional workplaces operate. More importantly, I have spoken to many executives from a variety of sectors, who have concluded with surprise, that they are actually able to do many of the things remotely, that they previously were sure had to be done in person, in the office, face to face. Accordingly, it is reasonable to assume that organisations are going to use the experience of COVID-19 enforced remote working to review their estate & people strategies, with the likely outcome being less office based working, more home based staff, & greater use of true hot desking, all rapidly underpinned with technology providing a secure & seamless work experience wherever the user happens to be. Sounds great, doesn’t it? The fundamental problem here is that the words “seamless work experience” and “secure” are rarely found in the same sentence, particularly if the word “rapidly” is there too! In my experience, when executive teams are faced with the need to compromise something to achieve a vision it is often “secure” that is squeezed, particularly if the solution is to be delivered through “Agile” or “Lean” methodologies. As an example, I will cite my experience supporting a global enterprise that was undergoing a fundamental transformation programme, championed by a charismatic COO. The COO had set extremely tight timescales for completion, and a loose programme of semi-independent “Agile” project teams to deliver aspects of the solution. The enterprise had a well defined & documented risk appetite, linked to the heavily regulated sector it operated in. However, it was quickly apparent that the outcome of the transformation projects would lead to a situation where the organisation was operating well outside its stated risk appetite and risking regulatory action. How had a global enterprise got into such a situation? In simple terms, the answer was that the CSO & CISO were entirely disengaged from the transformation process, and the project teams were primarily driven by the need to deliver within the tight timescales. What contact there had been from the security team was seen as a “problem” and “unnecessary process” inhibiting delivery. Despite there being a comprehensive Risk Register, that was regularly reviewed by a Board Risk Committee, none of the security related risks were scored highly enough to merit Committee attention, so the security issues with the transformation programme were never subject to proper scrutiny. So, what are the lessons here for CSO’s & CISO’s as their organisations look to the future?
    • The key lesson is do not allow yourself to be marginalised when fundamental change is being planned, you will not be thanked if a programme is derailed in-flight due to security issues that should have been flagged earlier
    • The Risk Register is your friend. If you can get your risks before a Risk Committee or Executive Team, and be able to articulate them in a positive & constructive way, you are far more likely to see them addressed
    • Make sure that you are either present or represented on Change Boards, and ensure that your concerns are recorded
    • If you do not have a Board or Ex Team position, escalate early
    • Finally, remember that done well – security is a business enabler!
Uncategorized - 05/27/2020

Hostage Negotiation and Cyber Security

Hostage negotiator

 

In one of my past lives, before cyber security came along, I was a hostage negotiator.

To give you an idea of just how long ago, during my training we were negotiating (through an interpreter) with “terrorists” who were holding “hostages” in a (very real) airliner, surrounded by (also very real) armed police, parked just off one of the (very busy) runways at London’s Heathrow Airport.

Unexpectedly, I had an up close and personal experience of being very, very close to a BA Concorde taking off at dusk, on full afterburners. I’m not sure that my hearing has been the same ever since!

Many people will have formed their view of hostage negotiating from watching movies, such as Dog Day Afternoon (my favourite), The Negotiator, and Inside Job, but in reality the art of negotiation is much less driven by a charismatic individual with a good haircut and a worrying appetite for risk and rule-breaking, and is much more of a disciplined team sport.

I have been asked many times, is there any similarity between the worlds of hostage negotiation and cyber security and – having given this some considered thought – the answer is yes.

So, here are my top two similarities:

 

1) Both rely on a strategy and an agreed risk appetite

Hostage Negotiation

In a complex and protracted hostage negotiation a Negotiator Co-ordinator who will be part of the Command Team determining the strategy & approach to resolving the incident will be appointed (I was one). On occasions, such as terrorist incidents, there can be political interest (which can affect the risk appetite), and the involvement of other agencies such as military special forces (which brings whole new dimensions of risk).

The job of the Negotiator Co-ordinator is firstly to be part of the Command Team to advise on how negotiation can support the overall incident resolution strategy and – once this has been agreed upon – to determine and execute a negotiation strategy.

As the incident unfolds, the strategy may have to evolve, and negotiation may be kept going to buy time whilst other options are made ready.

Cyber Security

In organisations where cyber security works well the CIO or CISO will play an active part in determining the overall organisational strategy. They will advise on how effective security can be a business enabler, and determe what constraints are necessary to achieve the level of security needed to meet the organisation’s risk appetite, bearing in mind legislation and regulation. They are then accountable for the delivery of various aspects of that strategy.

Unfortunately, in my experience it rarely happens like this. More often, the CIO or CISO do not have a seat at the table where strategy is developed and are often tasked with somehow creating an “appropriate” level of security, reactively, as in: after decisions have been made. This often leads to conflict, particularly in organisations embracing “agile” software development, where the very “agile” nature of the methodology can conflict with the stated organisation’s risk appetite and be almost impossible to secure.

Worse, in many cases there simply isn’t an agreed risk appetite, or simply a blanket statement which is meant to cover all aspects of an organisation from R&D (by definition high) to Audit (by convention low).

In either case, things work more smoothly, and with a greater chance of success if the Co-ordinator / CIO / CISO is an active and continuing part of the decision-making function.

 

2) Success is not achieved in isolation and works best when exercised

Hostage Negotiation

A peacefully negotiated outcome is always the aim of any negotiation, but contingencies always need to be made for a situation where negotiation is not possible or fails. These contingencies will always involve a host of other agencies, each of whom needs to understand their role in a hostage taking incident, and how they will interact with the other agencies present.

A critical factor is absolute clarity about which organisation and which person in that organisation is in overall command of the incident, whilst having cognisance of the power vested in stakeholder groups. So, for example, the person in charge of a hostage taking incident (most likely a cop) can do most things, but deploying the SAS requires Ministerial approval (as I found out the hard way on an exercise).

Cyber Security

Responding to a major cyber security incident will involve many internal teams (e.g. IT, Comms, Legal), may well have Board oversight, and will probably involve external specialists. In addition, regulators, law enforcement, the media, customers, and investors (to name a few) will need to be kept up to date.

This is far from easy, and there are many high-profile examples in major corporations of where it has gone wrong, particularly when it comes to communication strategy.

The simple answer, reinforced by governments around the world, is that this works much better if there is an Incident Response plan (worryingly many organisations, even surprisingly big ones fail at this), and works even better if said plan is exercised regularly (very few organisations actually engage in Incident Response simulations).

I have run many such exercises, and – spoiler alert – will often tell the key individuals everyone else looks up to for decisions, they are 30 minutes into a 12 hour flight, therefore out of play for the first 11 hours. Whilst this has never made me popular, it does tend to highlight how well decision making can work (or often not) in the absence of key players.

Just as in a hostage negotiation, roles and responsibilities need to be clearly defined for cyber security to deal with a crisis. Who can call in the SAS (or more likely turn off a company’s Internet connection?) if the need arises.

One final note: whilst I had a very cool “Hostage Negotiator” baseball hat – for the very essential purpose of not being shot by friendly fire – I have yet to see a cyber security equivalent!

Uncategorized - 03/11/2020

The industry guide to being a successful “bad actor”

We thought we would provide a guide to anyone looking to be a bad actor/malicious adversary/evil hacker based on much of what we have been hearing from the security industry at large.   1) Discuss all your evil plans on any site that is probably visited by "threat intelligence analysts". A good place is the dark web, go there, talk about your plans, but make sure people can find you. 2) Talk about your evil actions at a con. 3) Always choose the most difficult, ultra complicated vulnerability to exploit (even when you don't have to) 4) Don't try to buy any of the security tools your targets may use, because you can't. 5) Skip over testimonials on any security companies website, what possible use is it in knowing who provides security assistance to your target? 6) Also, don't waste time trying to find out more about the aforementioned security companies, its just going to slow down you succeeding in your attack. 7) Be sure to use the word 1337 a lot. 8) Disclose all your discovered vulnerabilities, its only fair. 9) Participate in bug bounty programs and post on twitter about it. Remember fame is the key to being a successful bad actor. 10) Participate in corporate CTF's. You can win prizes and show off your attack methods. 11) Ignore all the ATP and malware reports. This stuff is no use to you, just because everyone else collects intelligence doesn't mean you should. 12) Get some certs, you need certs to show you are good at this stuff to other like minded people. 13) Worry about anti-virus, its good, really. 14) Avoid all companies who have to meet published compliance standards. They know you know their controls, and are ready for you. 15) LinkedIn is useless for recon, its just full of motivational quotes. 16) Stick to one communication method, why complicate matters for yourself? 17) When you send a phish, be sure it looks like an iTunes, amazon, or other receipt. 18) By default, security monitoring/detection tools like well known attack patterns, so be sure to use them. 19) Only perform your malicious activities between the hours of 9-5 in whatever time zone the target is in. 20) Pick out a flattering and intimidating costume and choose a cool handle. 21) Fear security awareness training, it has the magical power of overcoming some of the traits developed during a life - fear, obedience, greed, helpfulness - all succumb to the power of posters, power-points, and  catchy slogans. 22) Brag about everything you do, again, fame is the key. Ever seen a Bond movie? the bad guy always tells James Bond his plans in detail, this is a sign of confidence. Do the same.   ***The authors of this article take no responsibility for its accuracy, the information contained within should not be considered as advice***
Uncategorized - 11/14/2019

Everyone can be taught new tricks – considerations for application pen tests

Application security is one of the areas that we put a great deal of our consulting efforts into and we perform  many web application penetration tests (WAPT). Overtime, we've seen a shift in the technical landscape and I wanted to write up something  for others to chew on.   The way to approach a WAPT has changed because application architecture and security technologies  are constantly evolving. Much of this is due to the adoption of the "cloud" and the seemingly endless new functionality being rolled out. We do quite a bit of in-house development and  often see a disconnect in how applications are developed and deployed, versus the technologies that are assumed to be in use when WAPT's are performed and in how automated tools are used for testing.   Initially, deployments started off as monolithic architectures with separate, independent layers of concern. The presentation layer serves the client interface, the business layer handles server side functionality and business logic, while the data layer is storage. This is where we have our LAMP stack deployments, along with Apache Tomcat RCE, WordPress Code Execution, webshells, and cgi-bin argument injection. You know, all the good stuff that we know and love. You obtain a foothold on the server, escalate privileges or move laterally, gain persistence, exfiltrate data, and call it a day. We continue to see a plethora of these deployments in the wild, however the technology in use isn't standard anymore, and to be successful a WAPT needs to consider this.   Let's say the application in scope for security testing is a Single Page Application (SPA) using React or Vue, with Redux and Redux Saga to handle state management. The SPA is deployed in an S3 bucket with CloudFront to handle content delivery, with the new shiny AI driven WAF to handle low hanging fruit and with signature detection and behavioral anomaly analysis. Authentication and authorization is handled using Amazon Cognito, Okta, or Auth0, with JWT for identity. The application client-side business logic is GraphQL queries to a serverless API endpoint using AWS API Gateway and Apollo Lambda Functions. For data storage it uses Neptune.   What if the SPA interacts with a API Gateway, and behind that gateway is a micro-services fabric cluster with key rotation using Vault for authorization of inter-service communication?   These architecture examples highlight some of the ways in which applications are deployed into cloud infrastructure. It allows for rapid deployment, decoupled services for scalability, and increased agility and efficiency. A production JAMStack application using Gatsby and AWS Amplify can be deployed in no time and the developer would never have to worry about the underlying infrastructure, patch management, or scalability.   As a penetration tester, what is your WAPT approach? How do you ensure you've covered the application effectively?   The inner monologue of a  penetration tester may unfortunately sound something like this when confronted with newer application architectures:  

"Doesn't matter, I'll fuzz the crap out of it and find the vulnerabilities eventually"

"Input validation is still input validation, let me at it and I'll dump that database in no time."

"I'm going to pop a webshell on that server, dump credentials, and own that network."

"Okay, let's run the vulnerability scanner and see what we get back."

 

You get the point, this can lead to ruin. Assuming the technology based on previous training, books, and lack of development exposure when doing WAPTs can lead you down the wrong path. Reconnaissance has always been an important part of an engagement, this is even more true today.   **Understand the architecture before you waste you and your clients time.**   Why are you trying payloads for Angular Template Injection when the client side is written in React? How are you going to determine, or would know if state management is mishandled? Why are you checking for authentication cookies when it's using JWT? Is JWT properly implemented?   If you happen to be an application developer reading this you're at least cracking a smile. The application security folks are as well, since they likely understand these deployments and the available security considerations that go into these architectures. The days of a developer not knowing how to handle authentication or authorization correctly are slowly going away with the shift in reliance on cloud providers and third-party services. Why roll my own auth when I can use Cognito? What I'm saying is the default security posture of applications is getting more mature as the application development and application security ecosystem continue to progress. More mature, but still not secure.   As mentioned before, the gap is in the offensive security tools and the assumptions we make when approaching WAPTS. Using common security tools on an engagement tends to lead to false positives and traditional coverage of HTTP interfaces, but can't handle REST APIs without contextual awareness. Client-side state management and front-end logic handling throws tools for a loop. Handling GraphQL endpoints in an automated fashion is almost out of the question.   On to manual testing, since we are doing a pentest right? The offensive approach to cloud-native deployments is different than for traditional monolithic on-prem deployments, and puts a heavier focus on client site input validation, API testing, authentication, authorization, and business logic. There are no CSRF attacks when using JWT. Directory traversal is out of the question due to dynamic routing in SPA. You can't SQLi to dump credentials when using an Cognito endpoint. It doesn't matter if you RCE an underlying S3 bucket, instead you want code execution on the application server run-time environment. When approaching Lambda functions, S3, and container instances, at the OS level there has to be an understanding of what is AWS territory and what is client territory. See the shared responsibility model. Of course, these are some forced examples to make a point that the landscape has shifted.   Ultimately the point I'm trying to make is:   **The more you understand about development and deployment capabilities, and overall application security within the SDLC, the more effective the penetration test will be.**   It's an obvious statement I'm sure, but you can't be a truly effective offensive player if don't keep up with the defensive and production capabilities.   Now, it is important to understand that cloud-native architectures are not bulletproof, it's just a shift in the attack surface. Increased complexity brings a new array of issues, like mishandling of JWT tokens (https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/), improper input validation, leaking of secrets and access tokens in source control, and over-permissive authorization. This names a few, but the list goes on. Keep an eye on HackerOne's Hactivity (https://hackerone.com/hacktivity) for some examples. Remember, combine the human element with the increased need for speed and scalability and mistakes will always happen.   To effectively test an environment, consider your threat model and emulate those threats in your penetration tests along with a testing approach that stems from your understanding of the ecosystem. Additionally, consider doing a secure architecture review with the client to provide input on secure best practices and highlight potential issues that reside behind the scenes. We've found  a combination of these to be effective in ensuring coverage. Again, the more you understand about the applications architecture and it's business objectives the more effective your security work will be.   Take the time to keep up with full stack development capabilities, cloud-native architectures and the application security strategies that go with it. It's not always about security testing, and it's easy to get left behind if you aren't careful   At OccamSec, we are always striving to stay up to date on both development and app sec practices to steer our continued security research, and ensure our WAPT methodology is effective when testing the most bleeding-edge deployments.
Uncategorized - 10/01/2019

LinkedIn Pwnage: why we can’t all be friends

                                      persona abstract image

 

Last July an article appeared on the outline entitled “How to Beat LinkedIn: The Game”, it’s an entertaining read regardless of how you feel about LinkedIn. Ever since reading it, we’ve been thinking about writing up something on how we have used LinkedIn during our work.

 

How do we highlight the risk of a platform, one we use, in a constructive way?

 

LinkedIn is really good for recon. Project managers like to post updates on new technology deployments, companies post job ads, people are constantly updating their resumes with new skills they have learned from their jobs, and so on.

 

On one project, we were engaged to infiltrate a client using only social media. The diagram below shows how this was achieved (note, this company had a highly active security awareness program).

 

                              linkedin attack walkthru 

It was that simple, “hello” to login in two weeks.

 

Total effort: a couple of hours

 

Advanced technical knowledge required: zero

 

This is another example of social engineering, given the nature of social media and addictive nature of it, social media platforms are excellent forums for this kind of attack. People want connections, they want “likes”, “shares”, followers. Validation of others seems (for why you want to connect to them) to often come down to the connections they have - “this person has connections, therefore they must be real”. Some people will accept any connection (“The more connections I have the cooler I am!”). These are the initial targets, once you find a few of these you can connect to them, and then fan out from there.

 

After that it's a question of how much information can glean from connections without raising suspicion. We have learnt to avoid sending requests to anyone in legal, and IT security folk do tend to be trickier (although not as much as you would think). Marketing people are fantastic, as is anyone in sales.

 

As the walkthrough above showed, plain old human interaction can go a long way (the request for a date was entirely unsolicited we should add).

 

So how do you deal with this?

 

Ban social media use.

 

Ok so you can’t do that. Social media can be another target for security awareness training, however because of the basic human brain functions these sites stimulate, only a program of constant awareness training stands any chance. People want to be helpful, they want to make friends, and the dopamine buzz from receiving messages and getting likes is extremely powerful for humankind.

 

Alternatively, counter intelligence (or disinformation programs) can be utilized to pollute information available about your organization on social media. This is difficult given the terms of services of these sites; however, adversaries are unlikely to follow them. So, in the name of protecting your organization, you may want to investigate what can be done.

 

We’re not saying don’t use LinkedIn, or any social media, but be aware that it’s another conduit into your organization through those who work there and needs to be part of a security plan.

Uncategorized - 08/30/2019

privacy policy

Copyright  © 2020 OccamSec

524 Broadway, New York, NY 10012