Information Security and Cloud Computing

Just like other areas of information technology, information security landscape continues to change at a fast pace. The updated CISO MindMap for 2019 covers important changes in the security landscape. In some bright areas, technologies using machine learning (ML) to detect zero day attacks are getting better and integrating of threat intelligence platforms with security operations is making analysts’ job easier. However, a lot more work is needed to avoid errors in misconfiguration of Cloud services.

How many times people ask you about what you really do? Although the answer could be many things depending upon the context of the question and who is asking it, sending a copy of this MindMap could help. I have heard from many professionals that this MindMap is also helpful in explaining the complexity of a CISO job.

What is New?

There are some items in the MindMap marked in red color. These are either new or modified compared to 2018 MindMap. Also, take a look at the bottom-right box marked as “2019 Focus Areas” which lists some of the areas of your responsibility that you should pay attention to.

Following are some areas where I would recommend more focus for the remainder of the year 2019 and for planning next year activities:

Like this:

A 5-step process to evaluate and purchase Cloud security products and services

Verizon security recently published a white paper titled “CISO’s Guide to Cloud Security: What to know and what to ask before you buy” that points out five steps to help decision making on purchasing Cloud products and services. For each step, the white paper also provides recommendations to consider. This is a summary of this white paper.

Step 1: Assess your situation

According to Forrester research, 28% of enterprises have already moved to public Cloud, 44% are actively building private clouds. When you assess your situation, consider:

Where are you in the process of migrating to Cloud

What is your Cloud strategy? Cloud-first or Cloud-only?

Is this right time for you to move to Cloud?

Are you ready to move to Cloud?

Step 2: Define your requirements

To make sound decisions, defining security requirements and making sure the selected Cloud platform meets these requirements is essential. Following are recommendations from this white paper.

Scalability – Will the Cloud solution grow as your needs grow?

Extensibility – Does the platform offers APIs and other means to extend it?

Automation – Will you be able to automate routine security tasks in the Cloud?

Intelligence – Can you get contextual information for analysts and threat hunters?

Ease of Use – Is the user interface easy to use?

Step 3: Identify Use Cases

Legacy products may not be effective in Cloud environment. Adding new products for Cloud may not a good idea either. The recommendation is to identify use cases and consider the following:

How would you prove success of any Cloud security product or service? Consider building success metrics and dashboard with the following in mind:

Reduction in false alarms

Improvement in threat detection

Reduction in time for detection, deployment and dwell time

Increase in visibility and network coverage

Step 5: Evaluate your options

The white papers provides a sample table for evaluating different solutions that you can modify based upon your needs defined in steps 2 to 4 above.

When it comes to making purchase decisions for Cloud security products and services, this white paper provides a systematic approach for planning, evaluation, and decision making. The approach is not limited to a particular product or service and can be applied universally to any Cloud solution.

Like this:

Winning the perpetual fight against crime by building a modern Security Operations Center

I am happy to announce that first three chapters of my book “Cybersecurity Arm Wrestling: Winning the perpetual fight against crime by building a modern Security Operations Center” are available for download and your review. I am interested in getting your feedback on these chapters.

The initial three chapters are primarily focused on SOC planning, business case development, and making decisions about scope of log collection. You can download draft version from by clicking here.

Like this:

Collecting and processing security logs is one of the primary function of any SOC. Log sources vary widely, starting from security device logs, network components, applications, servers and many others. Collecting logs also needs significant investment in log storage and processing infrastructure. You want to prioritize log sources that bring the most value from security monitoring perspective. For these reasons, you should start with a small subset of log sources and expand the scope of log collection over time (in future phases of the project). While defining the scope of log collection for each phase, you can consider the following:

How a particular log source can help in incident investigations (reactive).

Amount of log data that you can handle, both from analytics and storage perspectives.

Compliance needs and requirements that a particular log source fulfills.

Typically, you should start with logs coming from security devices (firewalls, IDS, content filtering and proxy servers, identity management systems, proxies, VPN concentrators, end-point detection and response systems, etc.). The second preference may be server operating systems and public facing web server logs. Then you can move to applications, and so on. There is no prescribed order and you should define your own scope based upon your particular situation and which systems play a key role inside your organization.

With most of the organizations moving to Cloud, collecting logs from Cloud service providers like AWS, Azure, Google and others could become a priority for some organizations. Additionally, if you are using a Cloud Access Security Broker (CASB), collecting logs from CASB system in the initial phases of SOC implementation will also be a good idea.

For some manufacturing organizations, logs from IoT devices and operational technologies could provide significant value. Auto manufacturers could be interested in logs from connected vehicles.

You can also use threat modeling techniques to identify critical log sources and prioritize these accordingly.

Like this:

Many security vendors are published their threat reports and making recommendations to CISOs and other leaders for better protection of security assets. After reading many of these reports, following is a summary of major risks identified by these reports and strategies to mitigate these.

Ransomware

RISK – Ransomware is a form of malware that disables systems by encrypting data. The attackers demand ransom money to provide keys to decrypt data. Many organizations in diverse industry sectors have fallen victim to these attacks.

MitigationStrategy

Verifiable backup and mock exercise for timely restoration of systems

Patching for vulnerabilities to avoid infection by Ransomware

Monitoring network traffic for command and control centers activity and timely response to attacks

Network segmentation to stop lateral propagation

Phishing Attacks

RISK – Verizon Data Breach Investigations Report (DBIR) shows that phishing emails are one of the major point of entry for Cyberattacks. Employees fall victim to these emails and click on embedded URLs causing installation of a malware, creation of backdoors, or exfiltration of confidential information to attackers.

Mitigation Strategy

Robust awareness program

Web and Email content filtering

Include executive leadership in tabletop exercises (executives are being targeted more, per DBIR)

Espionage

RISK – Verizon DBIR and other industry reports show that Espionage is a real threat and accounts for 23% of data breaches, overall. Some industry sectors and public organizations with intellectual property are larger targets for espionage activity compared to others.

Mitigation Strategy

Understanding and document your risk profile and potential attackers

Build threat hunting and dark web investigations practice

Active monitoring of threats on networks and network segmentation

Effective awareness program

Move to Cloud

RISK – Most organizations are moving to Cloud or have a Cloud strategy. However, many organization have low skills to fully understand and implement controls for Cloud infrastructures (both at network and app levels) resulting in data breaches due to errors and misconfigurations.

Share this:

Like this:

Just published first chapter draft of the my latest book: “CyberSecurity Arm Wrestling: Winning the perpetual fight against crime by building a modernSecurity Operations Center“. This chapter is available for immediate download by clicking here. The chapter covers the following topics:

What is a Security Operations Center (SOC)?

What is a Modern SOC

What this Book is not about

Purpose:Why Build SOC?

SOC Business Models

What it takes to build a SOC

SOC Implementation: Incremental or Big Bang?

SOC Lifecycle Phases

Who are the stakeholders

SOCGoals/Perspective

The next chapters will be coming soon. Please download the chapter and provide your feedback.

Like this:

While there could be many definitions of what a connected vehicle is, following is how Wikipedia defines a “connected car”.

“A connected caris a carthat is equipped with Internet access, and usually also with a wireless local area network. This allows the carto share internet access, and hence data, with other devices both inside as well as outside the vehicle.” – Wikipedia

This post is part of a multi-series blog on security of connected vehicles. The focus of this post is describing Society of Automotive Engineers (SAE) definition of different levels of autonomy and exploring some stakeholders in the connected vehicle economy.

Is Connected-Vehicles the same as Autonomous?

Connectivity and autonomy are two different concepts. Most of the modern vehicles have some type of connectivity but not necessarily any level of autonomy. In many cases it is a matter of terminology about how people define a connected vehicle. Some may call it intelligent vehicle as well. However, please note that while there is a lot of buzz about “autonomous vehicles” or “self-driving cars”, every connected vehicle may be neither “autonomous” nor “self-driving”. The Society of Automotive Engineers (SAE) defined 5 levels of autonomy as shown below (SAE J3016) and connected vehicles may fall into any one of these (or neither).

Autonomy Level

Level Name

Description

0

No Automation

Human driver is fully responsible for driving vehicle.

1

Driver Assistance

Computers assist in steering, acceleration, deceleration

2

Partial Automation

Computers have primary responsibility for steering, acceleration, deceleration while humans act as a backup

3

Conditional Automation

Vehicles drives itself but human driver will respond to request for intervention from the vehicle

4

High Automation

Vehicle can drive by itself even if human does not respond to request for intervention

5

Full Automation

Full autonomous vehicle, can do everything that humans can do under all conditions

Who are the Stakeholders?

There is a perception that vehicle manufacturers are the primary stakeholders in connected vehicles. While they are the key stakeholder, there are many other parties who are involved directly or indirectly as part of the overall connected vehicle ecosystem.

Owners and Drivers – The owners and drivers of connected vehicles are directly involved as they have to understand how these vehicles work and ways to best utilize capabilities of connected vehicles. There is a good likelihood that you are already driving a car with some connectivity, intelligence and autonomy. There are more computers in all modern cars than we usually realize. Even if you are not driving a connected car, people around you on the road may be. You may be traveling and rent a car that is connected and you need to know how it works.

Transportation and Delivery – Many vehicle vendors already have connected vehicles/trucks on the road that are very much connected through telematics systems to measure efficiency of their transportation and delivery operations. A number of truck vendors are working on fully autonomous trucks for delivery with implications on jobs as well as improvement of productivity.

Taxi Business – The Taxi business has been using connected vehicles for quite some time but the new push is towards robo taxy where autonomous taxi service initiatives are under way. Well-known companies like Uber, Lyft, GM and others are working furiously towards this goal. There are many smaller and less-known startup companies in the race as well.

Critical Infrastructure Protection – People responsible for protecting critical infrastructure must be working on initiatives about how to deal with autonomous and semi-autonomous vehicles.

Food Delivery – Food delivery business is growing and there are a number of companies in the race. If you work in any food business, you should be thinking about how to utilize connected vehicles to improve your business, order taking, delivery scheduling and so on.

Smart Cities and Local Governments – Local governments are fully involved in providing the core infrastructure on which connected vehicles can better operate. This includes, but not limited to, initiatives like intelligent street signs, traffic lights, road sensors to provide data about road conditions, traffic congestions and so on. A compromise of integrity of data can wreak havoc. Information security professionals for city governments and smart city projects should actively work on creating a reliable and secure infrastructure for connected vehicles to be safe.

Internet Service Provider (ISP) – The ISPs are responsible for providing reliable connectivity to vehicles inside and outside of the cities. The demand for data consumed by connected vehicles is increasing, especially when it comes to full connectivity.

Gas Stations and Convenient Stores – Modern autonomous vehicles may show up on a gas station or convenient store without a drive for gas or pick up groceries. Companies in these business should be prepared to provide secure and reliable services to these vehicles. At this point, you have to treat vehicles as people as far as the services are concerned.

Insurance and Underwriting – There are new risk factors (or less risk in some cases) arising from connectivity and autonomy of vehicles. The insurance companies need to factor in the type of connectivity and autonomy in their risk models to come up with reasonable insurance costs. Hacking is a real threat for connected vehicles with strong implications for insurance industry.

Information Security – As alluded to some areas above, the information security professionals have added responsibilities when it comes to this emerging field. First of all, they need to better understand connected vehicles, use cases, threat vectors, and overall risk scenarios. Secondly they need to add vehicle security as part of their policies and procedures. Third, vehicle security, where it makes sense, should become part of security operations centers (SOC).

Federal Government – The federal government agencies must ensure that as autonomous vehicles come on roads, their software features and redundancy of control systems must follow high standards for the safety of other people on the road. A malfunctioning autonomous or semi autonomous vehicle can create significant damage on a road.

Conclusions

The above list is just a sample of who is a stakeholder in the connected vehicle ecosystem. This technology is changing the modern life and has a potential to change even more in coming years as we move to higher levels of autonomy. It is incumbent on the information security professionals to better understand the existing and upcoming technologies to be effective in their role and better enable their businesses.

Share this:

Like this:

Budget estimates are a major part of building SOC business case. A typical budget will consist of the following three major components:

Capital Cost– This consists of initial expense of building SOC and includes everything from furniture to hardware, software and external consulting fees.

Annual Payroll Cost– This includes salary and benefits for people running the SOC. Depending upon location and the size and scope of SOC, this can vary significantly. However, this is a major part of annual cost.

While estimating these costs, think about major cost buckets and get cost estimates from multiple vendors. For example, you may want to consider cost from multiple SIEM vendors by providing them high level requirements. Similarly, you can estimate number of IP addresses for subscription to network vulnerability scanning and application vulnerability assessment.

Estimating Number of People

The estimate for number of people may vary significantly depending upon whether you want to run a 24x7x365 SOC or something less than that. Following is one way of estimating number of people for 24x7x365 SOC.

Consider three shifts of 8 hours each. Also, consider 3 analysts in first shift and 2 analysts for each of the other two shifts. This will make 7 analysts on daily basis with 8 hours each, resulting in a total 56 hours every day. For the whole year (365 days), this will require 20,440 hours. Let us make it an even number of 20,000. Typically, one person will work for 2000 hours on annual basis, at the most. This means you need 10 analysts to run the SOC. You can divide these analysts into Tier 1, Tier 2 and Tier3. In my example, I estimate 5 tier 1 analysts, 3 tier2 analysts and 2 tier 1 analysts.

In addition to analysts, you will also need specialists like forensics and malware experts and a SOC manager.

If the SOC is not 24×7, your estimates will change accordingly. Based upon number of shifts, you have to create a schedule for these analysts and plan for vacation, training, and other situations. Typically, SOC manager will perform these duties.

We will have a separate blog posts about roles and responsibilities of each person and scheduling.

Estimating Technology Cost

As for as technology cost is concerned, you can explore options for Software as a Service (SaaS), purchasing perpetual licenses, or licenses with an annual cost. Vendors provide a number of options. You should keep about 20% of the software cost as annual maintenance fee but vendors can give you these numbers.

For initial SOC implementation, you will need external professional services. Vendors with expertise in building and running SOC can provide initial installation and tuning help to get the SOC up and running.

Build or Outsource?

For a comparison, you should also consider option for outsourcing the SOC. There are many vendors who provide “SOC as a Service” and bring their expertise to your benefit. Some vendors can co-manage SOC with your team, reducing the overall cost. You should explore all options as SOC is a major undertaking and needs significant planning.

Share this:

Like this:

Logs provide a wealth of information and that is one of the reasons that almost all security standards and frameworks (NIST, ISO, PCI, and others) emphasize on collection, storage, and analysis of log data as one of the key aspects of any security program. Collecting and managing logs is a fundamental requirement of any SOC implementation and is needed to meet many compliance needs.

However, as we know, some log sources provide much more value to security programs compared to others. So while you can collect, store and process all data you want, thinking about the true value can help you create a more cost-effective and focused strategy.

A phased approach for log management is always prudent where you start with important, more valuable log sources first and then add additional log data as your program matures.

While traditional log collection using Syslog protocols and log files has worked for quite some time, newer technologies are bringing challenges to log collection using older methods. With fast transition to Cloud based technologies, newer log data may come from SaaS applications, Cloud application platform, server-less applications, IoT devices, operational technologies, connected vehicles, drones, smart city technologies, and many others. These new log sources don’t always send logs with Syslog and may utilize APIs, web services, or Cloud services specially built for logging. While planning for collecting log data and building a log collection platform, all of these new options must be considered.

Distributed Log Collection

A distributed log collection architecture where local log collectors receive logs from different log sources and then forward to one or more central locations is commonly used today. This architecture helps in providing resiliency and reduction of loss of data in case communication link to central log collection becomes unavailable. The following diagram shows one such arrangement.

Welcome to brave new world of log collection using many methods to collect logs from Cloud, IoT, Vehicles, Drones, Operations Technologies, and others. Standing up a Syslog server is no longer sufficient.

A more distributed architecture can both collect as well as indexlog data locally and then make the indexes available to search requests from SOC analysts. This may be necessary to meet certain privacy needs like GDPR. However, one need to consider of the flexibility and scalability of distributed log collection infrastructure with the cost of managing it. As an example, indexing logs close to edge is attractive but it can create additional overhead in terms of correlation, reporting, alerting as well as cost of managing indexes at multiple locations. Needless to say that like everything else in life, there are some compromises to be made here as well!

Logging and NTP Protocols

A timestamp is an essential part of each log event. An important factor in building logging infrastructure is to ensure time synchronizing among all log sources to keep proper order of logs. Network Time Protocol (NTP) is commonly used for purpose. While NTP is a topic in itself, it is sufficient to at this point to understand that no logging infrastructure is complete until NTP is implemented to support it. Without it, log correlation and analytics will not work properly.

Logging Standards

Lastly, building logging standards to identify type, amount, and level of logging also goes a long way to build a consistent approach throughout an organization. A logging standard must address requirements for logging at different levels including system, middleware, and applications. The logging standards should also specify accepted logging protocols, storages and lifecycle of log data. Logging standards must be updated at least on annual basis to ensure new sources and types of important logs are taken into consideration based upon their value.

Summary

While building a scalable and distributed logging infrastructure, one should consider the following:

Use of local log collectors that could help in reliability, buffering, compression and bandwidth saving

By taking into account the above factors, there is a much better probability that you will be able to build a better logging infrastructure that grows with your needs, reduces cost, is more efficient and resilient, and brings more value towards managing risk.