Book: Cybersecurity Arm Wrestling – Chapters 1-3

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.

Subscribe to my blog

Posted in SOC | Tagged , , | Comments Off on Book: Cybersecurity Arm Wrestling – Chapters 1-3

Security Operations Center (SOC): Prioritizing Log Sources

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:

Continue reading
Posted in InfoSec, SOC | Tagged , , | Comments Off on Security Operations Center (SOC): Prioritizing Log Sources

Major Security Risks and Mitigation Strategies for 2019

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.


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.


  • 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)


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.

Mitigation Strategy

  • Better integration of network with Cloud virtual environment
  • Monitoring Cloud environment for potential misconfiguration issues
  • Implement Cloud security strategy and controls such as Cloud Access Security Broker (CASB)

Security of Emerging Technologies

Risk –  Emerging technologies such as machine learning, blockchain, IoT, and others are bringing new opportunities and at the same time creating additional attack surface.


  • Create internal expertise and a learning culture for these new technologies
  • Proactively create policies and procedures for security of emerging technologies
  • Engage with internal teams who are planning for using these technologies for better collaborative strategies
Posted in InfoSec | Comments Off on Major Security Risks and Mitigation Strategies for 2019

SOC Book: Chapter 1 Available for Download

Cybersecurity Arm Wrestling Title

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:

  1. What is a Security Operations Center (SOC)?
  2. What is a Modern SOC
  3. What this Book is not about
  4. Purpose:Why Build SOC?
  5. SOC Business Models
  6. What it takes to build a SOC
  7. SOC Implementation: Incremental or Big Bang?
  8. SOC Lifecycle Phases
  9. Who are the stakeholders
  10. SOCGoals/Perspective

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

Posted in InfoSec, SOC | Tagged , | Comments Off on SOC Book: Chapter 1 Available for Download

Security of Connected Vehicles Part II: Reference Material

Security of Connected Vehicles - Presentation at ISSA InfoSec Summit

Following is the list of reference material for my presentation on connected vehicles to the ISSA Infosec Summit on May 23rd.

University of Toronto also offers a connected vehicles training program on Coursera which many people may be interested in. It has some pre-requisites like linear algebra, machine learning, etc.

Posted in Leadership | Comments Off on Security of Connected Vehicles Part II: Reference Material

Security of Connected Vehicles – Part I

Credits: Pexels

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 LevelLevel NameDescription
0No AutomationHuman driver is fully responsible for driving vehicle.
1Driver AssistanceComputers assist in steering, acceleration, deceleration
2Partial AutomationComputers have primary responsibility for steering, acceleration, deceleration while humans act as a backup
3Conditional AutomationVehicles drives itself but human driver will respond to request for intervention from the vehicle
4High AutomationVehicle can drive by itself even if human does not respond to request for intervention
5Full AutomationFull 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.


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.

Posted in Leadership | Comments Off on Security of Connected Vehicles – Part I

Estimating SOC Budget

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.
  • Annual Recurring Costs– These costs include annual licensing fees, equipment depreciation, skills training, threat intelligence feeds, and general IT 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.

Enable email subscription to this blog by entering your email address below:

Posted in InfoSec, SOC | Comments Off on Estimating SOC Budget

Scalable Log Collection as Foundation of SOC

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.


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

  1. Use of local log collectors that could help in reliability, buffering, compression and bandwidth saving
  2. Understanding that modern log collection needs support of diverse log collection mechanisms that include Syslog, APIs, IoT protocols like MQTT, plain text files, XML, binary logs and others
  3. Prioritize logs sources based upon their contributed value towards better risk management and threat detection or response
  4. Use NTP in conjunction with the overall logging infrastructure to ensure proper order and correlation of logs
  5. Build logging standards to bring consistency and clarity of logging requirements

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.

PS: Subscribe to my blog at and follow on Twitter @rafeeq_rehman


Posted in InfoSec, SOC | Tagged , , , | Comments Off on Scalable Log Collection as Foundation of SOC

Announcing Cybersecurity Learning Saturday

Continuous learning and skills development is an essential part of any Cybersecurity professional but they don’t get enough time during normal work week. So why not turn Saturdays into a collaborative learning events where people come to share knowledge, teach, and learn on select topics related to Cybersecurity? My new initiative is launching “Cybersecurity Learning Saturday” which is summarized using the following few points:

  • Make Saturday a learning and skills development event as well as help you earn CPE credits to meet requirements for various certifications
  • Pick specific topics for day-long training sessions that will run in parallel
  • Bring expert volunteer trainers with expertise in these areas, who has a passion for sharing their knowledge.
  • Follow a specific standard training template for each session for consistency
  • Open the event for general community to attend where each learner picks up one of the topics, registers for the session, and gets a certificate of attendance at the end for CPE credits

With these objectives in mind, Cybersecurity Learning Saturday will become a learning event where professionals can pick a topic of their interest and join a day-long training session to upgrade their knowledge and skills. The proposed topics include but not limited to security certifications, Cloud security, security of DevOps, SOC, different types of security assessments including network and application security, and secure coding for web application developers.

The first Cybersecurity Learning Saturday will be held on March 2nd, 2019 in Columbus OH. I hope to see you in this event! Registration will start soon.

P.S. If you have passion for sharing your expertise and be a trainer for one of these sessions, don’t hesitate to contact me!

Related Links

Posted in InfoSec | Tagged , | Comments Off on Announcing Cybersecurity Learning Saturday

The Sorry State of Measuring SOC Success

While doing research on my upcoming book about running a successful Security Operations Center (SOC), I have interviewed people who have built and run SOC as well as survey reports from organizations like SANS and others. Overall it is a sorrow state of affairs where almost half of the organizations have no metrics for measuring the success of SOC implementations. The ones who have a metric, are mostly using non-business focused measurements to gauge performance of the SOC. Some are using metrics just to justify a particular technology investment.

Most of the people are not focusing on automation (doing manual work).

There is a lot of work that needs to be done to make a SOC efficient and real metrics to demonstrate business value!

Posted in SOC | Tagged | Comments Off on The Sorry State of Measuring SOC Success