Gain insights into cyber security fundamentals, explore common threats, discover protection mechanisms like firewalls, learn monitoring and response strategies, and develop secure systems as a developer.

Modern computer systems are almost universally connected, which creates wider attack surfaces well beyond code to users, hardware, and more. Securing systems is thus a fundamental skill for modern software engineers.

This course is a comprehensive introduction to cyber security best practices. You’ll start with an overview of common threats and vulnerabilities, as well as high-level concepts like privilege, integrity, logging, and mediation. With these concepts in mind, you’ll then learn common protection mechanisms and defense strategies from endpoint protection to firewalls, gateways, and proxy servers. Next, you’ll learn monitoring and detection techniques, alerts, and event management. Finally, when you detect a threat, you’ll know how to respond with support tickets, data preservation, and change management.

By the end of this course, you’ll have a better understanding of modern cyber security practices and a clear roadmap to implementing these as a developer.

Cyber Security Best Practices for Developers

## Overview

Compared to alerts and events, security incidents are thankfully rare. An organization will experience many different types of security events of varying severity daily. On the rare occasion that an event is severe enough to be classified as an incident, an **incident response plan (IRP)** should be used. Criteria should be defined in advance to determine whether the event should be treated as an incident.


## Creation of an IRP

How an organization defines security incidents versus events should be determined well before an IRP is used. 

- The definition of what constitutes an incident should be clear and based on quantifiable and objective criteria. 

- Once they’re defined, the next step is to create the corresponding incident response plans.

 - After the plans have been created, they need to be made readily available to those executing them. 

- Following the rule of least privilege, the confidentiality of the plan should also be enforced so that access to the IRPs is restricted to only authorized individuals.


## Review IRPs regularly

Once created, the IRPs should be reviewed regularly. The best method for identifying flaws or improvement opportunities with an IRP is to review and exercise the plan. A review may conclude that a plan is no longer relevant or necessary, at which point it can be retired and removed from the IRP repository.


The following section discusses creating and maintaining an effective incident response plan.

## Incident response plan (IRP)

An IRP should be developed well in advance of an actual incident. The worst time to develop a plan is when it’s needed. To help decide which incidents to prepare for, we should choose from attacks our organization is most at risk for. News coverage of past incidents suffered by other organizations can also help identify scenarios to prepare for.


Several elements go into an effective IRP. These include the following :

- The roles played by different members of the response team.

- The proper way to communicate updates about the incident as it’s handled.
 

- The necessary resources to facilitate a quick response. 

The following discusses these elements in more detail.

### Roles

Each individual on an incident response team (IRT) should serve a specific function. Sometimes resource constraints cause an individual to serve more than one role. Either way, these are the functions provided by a well-defined IRT.


#### Coordinator

The coordinator serves as the leader of the incident response team. Like a conductor leading an orchestra, an IRT coordinator ensures that team members are fulfilling their roles. In addition to keeping the team on track, the coordinator ensures that the team has the resources needed for the duration of the response. The person serving this role needs to be able to think on their feet, as the incident response process may change directions several times until resolution.


#### Scribe

The team’s scribe is responsible for documenting everything that takes place throughout the incident response. The form of the documentation can be an electronic document used for later review or a PowerPoint presentation slide displayed on a large screen for the entire team to view for updates. The documentation captured should be preserved for analysis once the incident is resolved. It could potentially support investigations by law enforcement or the human resources (HR) department.

#### Communicator

This person is in charge of delivering throughout the incident response process. Different kinds of people require updates and information, such as the operations teams, leadership, executives, and customer support teams. The delivered messages need to be tailored to their respective audiences. Defining them, knowing what they need, and being aware of how to communicate with them effectively will serve the communicator well at the time of an actual incident. For smaller teams, the coordinator can also serve as the communicator.


#### Analyst(s)

There may be more than one analyst on a response team, each focused on a different aspect of handling the incident. Focus areas can include malware analysis, root cause analysis (RCA), intelligence gathering, and identifying how to return operations to their default state. Analysts may also apply curative actions, such as deploying new AV signatures or creating scripts to remove malware from endpoints. The actions taken should be under the direction of the coordinator so they don’t conflict with policy, destroy evidence, or cause more damage.


### Communication

A communication tree is a list of individuals who should be notified and remain updated whenever an incident occurs. However, this is more than just a simple list of individuals to send emails to. It has the following properties:


- The message needs to be tailored to the recipient. For example, leadership will probably not want to know the technical minutiae that goes into root cause analysis (RCA). Similarly, not all security analysts need to be aware of the updates that leadership provides to the board of directors.


- In addition to contact information for individuals, a well-defined communication tree will include the different types of information that should be communicated and who the appropriate audience is for each.


- The messages should be consistent, understandable, and relevant to whoever is receiving the updates and status messages.

### Resources

A team will need certain inanimate resources available to respond to an incident and will need them at the start of the response. Key resources include the computers needed to perform the work. These may be the same equipment used for day-to-day operations (, or if there’s a war room (a location dedicated to responding to security incidents), the equipment there needs to be operational and ready to use. The following is a list of equipment that should typically be provided to all responders:


- Desktop or laptop PCs.

- Operating systems and applications with current patches and updates.


- Network connectivity.

- Phone.

- Chatrooms or instant messaging.

- Access to the latest information about the incident, such as a centrally-displayed dashboard that the entire team can view to get updates.


It’s preferable to have access to an internet connection that’s not connected to the organization’s network. This network connection should also ensure non-attribution, as it will be used to perform research and intelligence gathering. It should be assumed that when an incident takes place, the attacker is monitoring the response in some fashion, such as watching for connection requests from the target to IP addresses owned by the attacker.

Using a non-attributable internet connection avoids providing useful information to the attacker, who may be watching. Therefore, incident response analysts should have access to a device on the internal network to use internal email, chat, and other resources. In addition, responders should also have access to a separate internet connection that’s not associated with the production network.






# Overview

Compared to alerts and events, security incidents are thankfully rare. An organization will experience many different types of security events of varying severity daily. On the rare occasion that an event is severe enough to be classified as an incident, an **incident response plan (IRP)** should be used. Criteria should be defined in advance to determine whether the event should be treated as an incident.


# Creation of an IRP

How an organization defines security incidents versus events should be determined well before an IRP is used. 

- The definition of what constitutes an incident should be clear and based on quantifiable and objective criteria. 

- Once they’re defined, the next step is to create the corresponding incident response plans.

 - After the plans have been created, they need to be made readily available to those executing them. 

- Following the rule of least privilege, the confidentiality of the plan should also be enforced so that access to the IRPs is restricted to only authorized individuals.


# Review IRPs regularly

Once created, the IRPs should be reviewed regularly. The best method for identifying flaws or improvement opportunities with an IRP is to review and exercise the plan. A review may conclude that a plan is no longer relevant or necessary, at which point it can be retired and removed from the IRP repository.


The following section discusses creating and maintaining an effective incident response plan.

# Incident response plan (IRP)

An IRP should be developed well in advance of an actual incident. The worst time to develop a plan is when it’s needed. To help decide which incidents to prepare for, we should choose from attacks our organization is most at risk for. News coverage of past incidents suffered by other organizations can also help identify scenarios to prepare for.


Several elements go into an effective IRP. These include the following :

- The roles played by different members of the response team.

- The proper way to communicate updates about the incident as it’s handled.
 

- The necessary resources to facilitate a quick response. 

The following discusses these elements in more detail.

## Roles

Each individual on an incident response team (IRT) should serve a specific function. Sometimes resource constraints cause an individual to serve more than one role. Either way, these are the functions provided by a well-defined IRT.


### Coordinator

The coordinator serves as the leader of the incident response team. Like a conductor leading an orchestra, an IRT coordinator ensures that team members are fulfilling their roles. In addition to keeping the team on track, the coordinator ensures that the team has the resources needed for the duration of the response. The person serving this role needs to be able to think on their feet, as the incident response process may change directions several times until resolution.


### Scribe

The team’s scribe is responsible for documenting everything that takes place throughout the incident response. The form of the documentation can be an electronic document used for later review or a PowerPoint presentation slide displayed on a large screen for the entire team to view for updates. The documentation captured should be preserved for analysis once the incident is resolved. It could potentially support investigations by law enforcement or the human resources (HR) department.

### Communicator

This person is in charge of delivering throughout the incident response process. Different kinds of people require updates and information, such as the operations teams, leadership, executives, and customer support teams. The delivered messages need to be tailored to their respective audiences. Defining them, knowing what they need, and being aware of how to communicate with them effectively will serve the communicator well at the time of an actual incident. For smaller teams, the coordinator can also serve as the communicator.


### Analyst(s)

There may be more than one analyst on a response team, each focused on a different aspect of handling the incident. Focus areas can include malware analysis, root cause analysis (RCA), intelligence gathering, and identifying how to return operations to their default state. Analysts may also apply curative actions, such as deploying new AV signatures or creating scripts to remove malware from endpoints. The actions taken should be under the direction of the coordinator so they don’t conflict with policy, destroy evidence, or cause more damage.


## Communication

A communication tree is a list of individuals who should be notified and remain updated whenever an incident occurs. However, this is more than just a simple list of individuals to send emails to. It has the following properties:


- The message needs to be tailored to the recipient. For example, leadership will probably not want to know the technical minutiae that goes into root cause analysis (RCA). Similarly, not all security analysts need to be aware of the updates that leadership provides to the board of directors.


- In addition to contact information for individuals, a well-defined communication tree will include the different types of information that should be communicated and who the appropriate audience is for each.


- The messages should be consistent, understandable, and relevant to whoever is receiving the updates and status messages.

## Resources

A team will need certain inanimate resources available to respond to an incident and will need them at the start of the response. Key resources include the computers needed to perform the work. These may be the same equipment used for day-to-day operations (, or if there’s a war room (a location dedicated to responding to security incidents), the equipment there needs to be operational and ready to use. The following is a list of equipment that should typically be provided to all responders:


- Desktop or laptop PCs.

- Operating systems and applications with current patches and updates.


- Network connectivity.

- Phone.

- Chatrooms or instant messaging.

- Access to the latest information about the incident, such as a centrally-displayed dashboard that the entire team can view to get updates.


It’s preferable to have access to an internet connection that’s not connected to the organization’s network. This network connection should also ensure non-attribution, as it will be used to perform research and intelligence gathering. It should be assumed that when an incident takes place, the attacker is monitoring the response in some fashion, such as watching for connection requests from the target to IP addresses owned by the attacker.

Using a non-attributable internet connection avoids providing useful information to the attacker, who may be watching. Therefore, incident response analysts should have access to a device on the internal network to use internal email, chat, and other resources. In addition, responders should also have access to a separate internet connection that’s not associated with the production network.






Learn when to classify events as incidents and how to proceed, including having an incident response plan to prepare for incidents.


Incident Response

Learn when to classify events as incidents and how to proceed, including having an incident response plan to prepare for incidents.

Introduction

Basics of Security

Detect

Protect

Respond

Conclusion

Incident Response

Overview

Creation of an IRP

Review IRPs regularly