Deception is the new black

First published in Modernciso

Concepts acquired from the military field are everywhere in cybersecurity – think defense in depth, situational awareness, intelligence, counter-intelligence… The list is long. In this post, I’m going to talk about one of them – deception – not because it’s new, but because I think it’s going to become really important in the upcoming years.

Deception as a concept applied to cybersecurity has been around for a while. It’s the idea behind honeypots, honeynets and honey tokens. What’s new is that these products are maturing, allowing simple but customized deployment and scalability thus making them suitable for corporate environments. The generic name given to these new products is Distributed Deception Systems (DDS).

To better understand the benefits of these solutions, we need to put on the shoes of an attacker. We’ll choose one who has successfully compromised a computer – by spear phishing, for example – in a network where deception points have been deployed across a wide range of vectors such as user accounts, office documents, network services, mobile phones, servers, printers, etc.

As an attacker, invisible, blanket deceptions can be a real nightmare. We can’t know which of the services and systems that we can see from the system we’ve compromised are authentic and which ones are deceptive. And the same thing happens with the local accounts that we can see and try to re-use on a different system.

In effect, we’re taking decisions in the dark. We’re blind. So, the result is that any wrong step we make, can trigger an alert that compromises all our attack efforts and puts our mission in jeopardy.

This is a real game changer. Previously, target organizations could never gain the upper hand. We were free to make all the attempts we wanted to and only needed one single success to win the battle. Defenders, however, needed to be successful all the time – one single mistake and they could lose the match.

Deception irons out some of the asymmetry in cyberwarfare. Thanks to deception technology, one single mistake will unmask us and enable the defenders to detect the attack before it’s too late.

Another big benefit of the DDS solutions for organizations is that the false positive ratio is usually really low since most of the time, only a real attacker will fall into the deception. On top of this, the quality and amount of information that the alerts provide is much richer than that obtained by traditional security solutions. Full control over what the attacker is allowed to do enables the organization to keep the attacker busy in order to obtain additional valuable information.

Because of this, these new deception solutions not only allow security teams to decrease the time to detection (TTD) after an asset has been compromised, but also will increase the attacker’s time to compromise (TTC), as they will require more time to find their objective and to figure out how to reach it without being deceived. Defenders increase the time they have to react to an attack and to learn from the attacker actions in order to be better prepared against future malicious activity, or even find out who’s behind the attack. And this can definitely make the difference between a headline-hitting mega-breach and just another failed attack.

We need to keep in mind that this breed of deception technologies is not going to replace the traditional approaches of detection and prevention but needs to be seen as a way to complement them by providing an extra layer of security that comes into play when the attacker lands on their target network.

So, watch this space. For the reasons I’ve listed, I’m convinced that in the upcoming years we’ll be seeing a massive adoption of those DDS technologies on corporate environments as well as a big increase on presence and maturity on the deception solution market.

GDPR: A Brief Overview

First published in Modernciso

Over a year ago the GDPR (General Data Protection Regulation of April 27th 2016) was approved and will become mandatory to the European Union members starting May 25, 2018.

That leaves a little less than a year to become compliant with the regulation, so I wanted to take the opportunity to write an overview about what this regulation is and what its main objectives are.

Let’s start by having a look at how this regulation defines personal data. “Personal data is any information relating to an individual, whether it relates to his or her private, professional or public life. It can be anything from a name, a home address, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer’s IP address,” according to the European Commission.

Here are the main principles the regulation lays out, for collecting data:

• Processed lawfully, fairly and in a transparent manner in relation to the data subject
• Collected for specified, explicit and legitimate purposes
• Adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed
• Accurate and kept up to date
• Kept in a form that permits identification of data subjects for no longer than is necessary
• Processed in a manner that ensures appropriate security including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage

Let’s have a look at the scope of the regulation, which organizations are obliged to adhere to. The regulation defines two figures around the data protection:

1. The data controller (the organization that is collecting data from EU residents)
2. The processor (the organization that processes data on behalf of data controller).

The regulation applies if either the controller or the processor are based in the EU or if they collect or process personal data of EU residents.

Let’s review now some of the main changes that the GDPR will effect:

• It expands the notice requirements to include the retention time and the contact information for the data protection officer
• Valid consent must be explicit for the data collected and the purposes of said data. Data controllers must be able to prove “consent” (opt-in) and consent may be withdrawn
• People will have the right to question and fight decisions affecting them that have been made automatically by using algorithms
• Implementing measures must be designed into the development of business processes for product and services which meet the principles of data protection by design and data protection by default
• Will be the responsibility of the data controller to implement and demonstrate the compliance even when the processing is carried out by a third party

The new regulation also obliges organizations to appoint a Data Protection Officer for all public authorities or when the core activities of the data controller or processor consist of operations that require regular and systematic monitoring of data subjects on a large scale, as well as when they need to process personal data on a large scale.

Another significant aspect of the new regulation is the notification of a personal data breach to the data subject when the breach is likely to result in a high risk to their rights and freedoms. The notification will need to describe in clear and plain language the nature of the breach and the likely consequences of the breach as well as the measures taken or proposed to address it.

This notification can be avoided if the controller has implemented appropriate technical and organizational protection measures, in particular those that render the personal data unintelligible to any person who is not authorized to access it, such as encryption.

Finally, let’s have a look at administrative fines, since it’s also a major change. It’s important to know that infringements of the regulation can be subject to administrative fines up to 20 million Euros or up to 4% of the total worldwide annual turnover of the preceding financial year, whichever is higher. In order to determine the quantity, the nature, gravity and duration of the infringement will be taken into account. Regulators will also take into account the nature, scope and purpose of the situations as well as the number of data subjects affected and the level of damage suffered by them.

Also, the intentional or negligent character of the infringement, the technical and organizational measures implemented, as well as any action taken by the controller or processor to mitigate the damage suffered by data subjects is considered. Also considered are previous infringements, the degree of cooperation in order to remedy it and mitigate the possible adverse effects. These instances will become known to the supervisory authority.

In any case, 20 million Euros or up to 4% of the total turnover is a really respectable amount that I’m sure will be good motivation for those companies that manage sensitive personal data to invest on being compliant with the GDPR and implement the needed technical and organizational controls to decrease the risk of having a personal data breach.

What about your company? Is it already working on implementing those controls and moving forward to get compliant with the GDPR?

Link to the law: http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e6226-1-1

From Waterfall to Scrum

The purpose of this post is to share my personal experience implementing Agile and DevOps methodologies on a development department that was working on waterfall approach.

Around one year ago the organization decided to move to agile development methodologies using a DevOps approach, with the help and guidance from an external company.

At first it was not easy to change the habits acquired over several years of project and was required a re-learning process for all project stakeholders; starting by the developers, following by the business and ending by the middle management.

For me personally, it supposed to start playing the role of Product Owner being my main task to help business owners on the definition of the goals and priorities for the medium and long terms and, on the other hand, I was carrying those objectives and priorities to the DevOps team creating and maintaining a prioritized backlog of user stories to be implemented.

Another important point was the adoption of the scrum rituals, from the 15’ daily scrum meeting to the bi-weekly demo in which the team can receive direct feedback from business about the new features developed. But I think the most important one was the retrospective where the team meets once every two weeks to make self-criticism devising and testing changes on the way they work with the objective of improving their results. Is this ritual the one that guarantees the continuous improvement for the DevOps team.

On the other hand, the move to DevOps supposed to add into the team infrastructure profiles so the team was fully autonomous to work without requiring other teams to provide systems, databases or other infra or technology pieces. So now, on each DevOps squad we can find a mix of developers, systems engineers, DBAs and other profiles. It has also meant that is the same team who provides the support on 24/7, so they are really motivated to deliver tested and quality code/systems.

Now, over a year after the start of this trip from waterfall to DevOps I really think it was a great success. I would summarize the greatest benefits as:

• Every Squad in the team is empowered and autonomous enough so teams are more motivated resulting in a clear productivity increase.
• There is a very big reduction of waste in managing teams and interactions between development and operation/infrastructure teams.
• The business receives more frequently deliverables and can provide feedback more regularly.
• There is an important reduction of the waste in drafting complex functional requirements that will eventually be changed in the future. Instead, user stories occur at the last moment, dedicating the necessary time and just before the team really start working on them (just on time stories creation).

As conclusion, I will say that to move to an agile way of working is the right decision if you need to run long projects with a big chance of having changing requirements but the main point is to have the support and commitment of the management for do such kind of big cultural and organizational change.

2 years in Switzerland

Hi there,

It seems it was yesterday when I wrote this other post about my first year in Switzerland. But the reality is that this was one year ago and that I’ve already been living and working in the Lausanne area for two years now. So, it’s time again to look back and evaluate the experience lived during this time.

I came to Kudelski Security to manage and deliver cybersecurity engagements to clients but quite soon appeared the opportunity for helping the team that was developing cybersecurity solutions for the CFC (Cyber Fusion Center) on their transition to Agile and DevOPS. Even if I hadn’t any practical experience in those fields before, I found very appealing the possibility of learning and collaborating on this transformation, so I assumed the position of being the first Agile Product Owner in the company.

But now, a new great opportunity has come up so I’m changing my role in the organization to become MSS (Managed Security Services) architect. That’s a challenging position that however will allow me to be closer than before to the cybersecurity topics and to participate deeper in the definition and built of the new MSS that the company will develop. As a member of the MSS leadership team I’ll be responsible for architecting the tools, systems and technology to support Kudelski’s MSS business globally. I’ll be collaborating with development, engineering and leadership teams to define and drive the operational execution of Kudelski’s MSS strategy.

In another vein, during the last year I got my GIHC certification, that is a good complement for the PMP and CISSP that I got in 2015 and the CISA, CISM and ISO27001 Lead Auditor that I already brought from Spain.

At personal level I’m really comfortable living and working in Switzerland. Now the stressful time of the first months when I needed to manage the movement, finding the apartment, doing all the required paper work are far away. My family is happy and adapted to live here, and we start to be able to understand quite a lot of French and even if we’re not able to use it at professional level, we can use it to survive in our day to day here.

On the other hand, even if it’s true that the winter is long and quite hard here, the summer is just gorgeous, with soft temperatures and amazing mountains, lakes and places to enjoy.

So I’m still enjoying and learning working and living here so I’m sure that was the right decision coming to Switzerland and joining Kudelski Security. Let’s see how it works during my third year here!

I’ll keep you posted. :-)

Mitigating Pass the Hash attacks

Pass the hash is not a new attack but a really old lateral movement kind of attack that has been exploited by attackers during the last 15 years. However, still today is really effective in Windows networks.

The purpose of this post is to give you an overview of how this attack works and what are the main security controls that you could put in place to prevent or mitigate it.

The attack consist on getting the password hashes from a compromised system and reuse it to get access into other systems of the network. This attack is possible in Windows due to how the NTLM protocol works; attackers can use the hash of a password to authenticate to remote services without needing the plaintext password or without having to undertake dictionary or brute-force attacks on the hash itself.

It’s not possible to prevent completely attackers using this technique in our Windows infrastructure, but there are some mitigation controls that we can put in place. These are the security controls recommended by Microsoft for that purpose:

• Restrict and protect high privileged domain accounts
• Restrict and protect local accounts with administrative privileges
• Restrict inbound traffic using host-based firewall

Let’s review each of them.

Mitigation 1: Restrict and protect high-privileged domain accounts

This mitigation reduces the risk of administrators inadvertently exposing privileged credentials to higher risk computers.

The idea is to restrict high-privileged accounts like domain and enterprise admin accounts from being used to authenticating to less trusted computers. So the admins should use less privileged admin accounts to perform their regular tasks instead of using high-privileged accounts. It’s important as well not schedule tasks or configure services with privileged accounts on lower trust computers.

The rationale behind this control is that an attacker cannot steal credentials for an account if the credentials are never used on the compromised computer.

This mitigation can only be technically enforced from Windows Server 2012 R2. Prior to this version, could only be enforced by policy or procedures.

Mitigacion 2: Restrict local accounts with administrative privileges

This mitigation restricts the ability of attackers to use local administrator accounts for lateral movement PtH attacks.

The idea is to enforce the restrictions available to prevent local accounts from being used for remote administration by explicitly deny network and Remote Desktop logon rights for all administrative local accounts.

On the other hand, as Windows is not using Salt for calculating the hashes or the passwords, local accounts with administrative privileges should have a unique password for each system.

With this control in place, an attacker who successfully obtains local account credential from a compromised computer will not be able to reuse those credentials in other computers on the organization’s network.

Mitigation 3: Restrict inbound traffic using a host Firewall

This mitigation restricts the ability of attackers to initiate lateral movement from a compromised workstation by blocking inbound connections.

The idea is to restrict all inbound connections to all workstation except for those with expected traffic originating from trusted sources. Using a ‘whitelisting’ approach in terms of sources and protocols will prevent an attacker who successfully obtains any type of account credentials to be able to connect to other workstations.

Other windows features that can help

Other windows features that could be useful to prevent an attacker from stealing or using stolen credentials are:

• Enforce credential removal after logoff
• Remove LAN Manager hashes from LSASS
• Remove plaintext credentials from LSASS for domain accounts
• Protected Users security group
• Authentication Policies and Silos
• LSA protection-theft
• Disable Automatic Restart Sign-on (ARSO) Routine

More info and conclusion

In that link: https://technet.microsoft.com/en-us/security/dn785092, you can find extensive information and more details about those MS features as well as deeper information about how and why the PtH attack works and how to prevent or mitigate it.

It’s important to keep in mind that there is no silver bullet for the PtH attacks. Technology alone cannot solve that problem, so people and processes become critical elements in any corporate defense program. The proposed security controls must be enforced and integrated into a comprehensive security approach that should include security awareness, security monitoring and incident response readiness.

Secure DevOps without dying in the attempt

As the Product

I’d like to be secure

To avoid hackers exploiting me and having fun at my expense

One of the things that I’ve been working on during the last time is about how to ensure that the security of the product is correctly managed through the agile lifecycle. And it’s not an easy topic since we don’t have a big up-front planning were we can expend the needed time to analyze the risks and set up the security requirements. In fact is the opposite, we are not sure of what we will be building some weeks after so planning security can be a really painful activity or even worst, we can decide to forget about security in our product or do it as “best effort”. But after consider it carefully, I really think it’s a good opportunity to increase security efficiency since we can also be agile on security; reassessing the risks with a higher frequency and being able to better adapt the countermeasures to the dynamic context where the product will be leaving.






But to be able to exploit this opportunity we will need a “security champion” collaborating with the DevOps team to guarantee the security risks are detected and managed on time. I don’t mean having a dedicated security architect by team but he should have some dedication at least once per sprint to ensure that no new risks are being introduced while the team develop the new stories.
This security specialist must work closely with the Product manager and the Product owner to understand what is the long and mid-term vision and roadmap for the product, so he can forecast what will be the risks and define the security requirements that would be taken in consideration by the scrum teams in the implementation.

He also need to have close interaction with the scrum members to understand how they will implement each story in order to be able to detect security risks coming from the implementation strategy selected in each case.
He’s also the one that should maintain up to date the risk register agreeing with the risk board the strategy to manage the identified risks and work with the Product owner to translate these risks management strategies into user stories to inject in the teams backlog.

On the other hand, as part of the continuous integration process,  the static code should be checked with a tool to detect any security vulnerability being introduced on the product, as well as vulnerability scans for the infrastructure and application vulnerability scan before to consider a release prepared to be deployed in production. Beside of that, periodically and always for each major release, it must be done a complete security audit before deploying the code into production, as well as a Pentest exercise over the infrastructure hosting the product.

Sometime I've heard also people afraid by the fact of the same team developing and operating the solution. Since it can be a risk on some cases, there is plenty of ways to mitigate it: peer programming, peer reviews, external audits, role segregation, etc...

Lastly but not least it will be fundamental to deliver proper training to the scrum team about secure code techniques since as in all the cases, the human factor is always the weakest link of the chain.

In conclusion, contrary to what is commonly believed, agility does not have to mean lack of security. In fact, as we have seen, it could become an opportunity to improve better security processes being smarter and more effective on the efforts that we dedicate to protect our product.

One year in Switzerland

One year ago I took an important decision when I quit my job as Security Specialist in Caixa d’Enginyers, a Spanish small bank and I moved with my family to Switzerland joining Kudelski Security as Cyber Security Officer. I remember that it was a stressful time: starting a new job in a new country, managing the movement, finding an apartment, doing all the paper work required, etc..

Now, one year later, I think it’s the right time to look back and evaluate the experience acquired during this first year.

At personal level, I’m quite happy with the change. It’s true that the lifestyle is a little different in Switzerland than in Spain; as you can imagine, there is less culture of leaving and eating outside, winter is really cold so it’s difficult to enjoy it unless you like to sky or other winter sports (and it isn’t my case), and the sum of these little things makes a big difference. It’s also true that people here are really kind and makes big efforts to facilitate the adaptation of foreign like me. On the other hand, considering the Spanish economic difficulties I really think it’s a good opportunity for the whole family.

At professional level, I’m also happy with the change. I’m improving my English, learning French and seeing new approach of doing things. Again, there are some little differences that together make a bigger one. I’m enjoying working with people from around the world so having big opportunities of learning and growing at personal and professional level. Some of my colleagues are really brilliant professionals and it’s a pleasure to learn from them as much as I can. It’s been also exciting to work in a ‘start up mode’ where things are evolving and changing continuously so I’m having the opportunity of doing really different things and I’ve learnt a lot during this first year here. For example, I’ve had the opportunity of working in risk assessment, cloud security, SOC services, security trainings, security project management and other security topics during the same year.

And that is what I really love; learning, having fun and getting paid for it.

So I can say that was the right decision coming to Switzerland and joining Kudelski Security. Let’s see how it works during my second year here! I’ll keep you posted. :-)