зеркало из https://github.com/mozilla/sep315.git
Update 04-incident-response.md
This commit is contained in:
Родитель
5d26f562ab
Коммит
9e32a3ada6
|
@ -1,16 +1,16 @@
|
|||
#
|
||||
# Incidence Response
|
||||
# Incident Response
|
||||
|
||||
So, we know there is an issue and we need to respond. We have to make some assumptions here, as the we don't have a legal department or other parts of the equation that would be an enterprise. The first assumption is that we are only moderately concerned attribution, which may seem like an odd statement, but most companies aren't interested in attribution, as it is hard to do and offers little in the way return on investment. Secondly, we are assuming that our make-believe enterprise doesn't have to worry about moving data across country lines or other HR issues that would be specific to different regions of the world.
|
||||
So, we know there is an issue and we need to respond. We have to make some assumptions here, as we don't have a legal department or other parts of the equation that an enterprise would. The first assumption is that we are only moderately concerned about attribution, which may seem like an odd statement, but most companies aren't interested in attribution, as it is hard to do and offers little in the way of return on investment. Secondly, we are assuming that our make-believe enterprise doesn't have to worry about moving data across national borders or other HR issues that would be specific to different regions of the world.
|
||||
Read Further:
|
||||
[IR Whitepaper](https://d1.awsstatic.com/whitepapers/aws_security_incident_response.pdf)
|
||||
|
||||
|
||||
## **Setup**
|
||||
|
||||
So, we know we have an issue, the first thing we need to do is decide how we want to deal with it. In this case we are going to assume that the enterprise is not interested in collecting data about bad actors. The two options are 1. Stop the bad actor, or 2. Observe the bad actor, and learn about them. As stated, we are going to follow option 1 and simply stop the attacker. In this case we have a comprised account and external SSH access.
|
||||
So, we know we have an issue, the first thing we need to do is decide how we want to deal with it. In this case we are going to assume that the enterprise is not interested in collecting data about bad actors. The two options are 1. Stop the bad actor, or 2. Observe the bad actor, and learn about them. As stated, we are going to follow option 1 and simply stop the attacker. In this case we have a compromised account and external SSH access.
|
||||
|
||||
We need to decide what to do fist. If we decide we want to stop the bad actor, we need to look at the different avenues of access. In this case the actor has access to your account and one of your instances. In this case, we should turn off account first in an effort to stop the bad actor from building new instances.
|
||||
We need to decide what to do first. If we decide we want to stop the bad actor, we need to look at the different avenues of access. In this case the actor has access to your account and one of your instances. In this case, we should turn off account access first in an effort to stop the bad actor from building new instances.
|
||||
|
||||
Step 1 – Removal of Control
|
||||
|
||||
|
@ -26,38 +26,38 @@ Browse to the AWS Console and go to the IAM service
|
|||
|
||||
![Picture3](img/Picture3.png)
|
||||
|
||||
- Here we can see that this use has Admin access. If we need to maintain this user for investigative purposes, we can simply remove the access that it has by remove the Policies that it has associated with it and changing the credentials. If a User that is associated with application is compromised, we may only want to change the access keys and password. We do this by clicking on the Security Credentials tab.
|
||||
- Here we can see that this user has Admin access. If we need to maintain this user for investigative purposes, we can simply remove the access that it has by remove the Policies that it has associated with it and changing the credentials. If a User that is associated with an application is compromised, we may only want to change the access keys and password. We do this by clicking on the Security Credentials tab.
|
||||
|
||||
![Picture4](img/Picture4.png)
|
||||
|
||||
- Here we can see that the use has been used recently. We also have the option to remove the access the they may have, by clicking the "X" near make inactive. In a real world scenario it may be a very good choice to click the "Make Inactive" button, if the comprised user has existed for a long period of time and developers may have used these credentials. You will also note that this user, is only able to login into the API, not the console, as the console password says that it is disabled. Also please review is the user has an SSH key. If they do this would mean that the bad actor could infect any products that this user has the ability to touch.
|
||||
- Here we can see that the user credentials have been used recently. We also have the option to remove the access the they may have, by clicking the "X" near make inactive. In a real world scenario it may be a very good choice to click the "Make Inactive" button, if the compromised user has existed for a long period of time and developers may have used these credentials. You will also note that this user is only able to use the API and not log into the console, as the console password says that this is disabled. Also please review if the user has an SSH key. If they do this would mean that the bad actor could infect any products that this user has the ability to touch.
|
||||
|
||||
## **SSH Traffic from the Outside**
|
||||
|
||||
Second, we need to correct the SSH traffic to a server that is on the open network. We have a multitude of choices to do this. The easiest two are:
|
||||
Second, we need to address the issue of SSH traffic to a server that is on the open network. We have a multitude of choices to do this. The easiest two are:
|
||||
|
||||
1. Changing the subnet in the SSH line, in the security groups to remove the ability of the general internet to connect to this port.
|
||||
1. Changing the subnet associated with the SSH line in the security group to remove the ability of the general internet to connect to this port.
|
||||
|
||||
2. Remove the SSH line altogether and use SSM to manage the system going forward, or build a bastion host.
|
||||
|
||||
**Tip** : Remember, if there is already an SSH connection to a server active, you will also have to place a NACL in place, break the session.
|
||||
**Tip** : Remember, if there is already an active SSH connection to a server, you will also have to set a NACL to break the session.
|
||||
|
||||
### **Breadcrumbs**
|
||||
|
||||
- Find the Security group/s that allow conventional SSH port: 22 (TCP)
|
||||
- Figure out the event format
|
||||
|
||||
**Note** : In a real environment, SSH may be running on different ports, so you might need some protocol analysis as well. Additionally, in some cases you might want to use different log sources, such as SSH logs themselves, if available - or use them in combination with other types of logs. The amount of data that is found in the flow logs can be very close between a successful and an unsuccessful connection, so it's not always reliable - but we also don't have perfect logging, and it's often sufficient. Remember to think out of the box!
|
||||
**Note** : In a real environment, SSH may be running on different ports, so you might need some protocol analysis as well. Additionally, in some cases you might want to use different log sources, such as SSH logs themselves, if available - or use them in combination with other types of logs. The data that is found in the flow logs can be very similar between a successful and an unsuccessful connection, so we can't always make a reliable judgement - but we also don't have perfect logging, and it's often sufficient. Remember to think out of the box!
|
||||
|
||||
## **Ok, you know how to do it by hand…**
|
||||
|
||||
### **Scenario (This is the hard part)**
|
||||
|
||||
In the real world you will need to do all of the above, over the course of half a second. You need to be able to automate all of it and do it quickly. In the real world, many of the actions that you would expect to do are pre written for you in things like CloudCustodian or Warden. Warden is described in another session here at re:inforce.
|
||||
In the real world you will need to do all of the above, over the course of half a second. You need to be able to automate all of it and do it quickly. In the real world, many of the actions that you would expect to do are pre written for you in tools like CloudCustodian or Warden. Warden is described in another session here at re:inforce.
|
||||
|
||||
### **What to do**
|
||||
|
||||
### In this exercise you will build two simple lambda functions to correct the above issues and a step function to control them. The goal of this exercise is not to make a full application that you can deploy to a production environment but rather to show to build a system that can help you as the student understand the possibilities both good and bad.
|
||||
### In this exercise you will build two simple lambda functions to correct the above issues and a step function to control them. The goal of this exercise is not to make a full application that you can deploy to a production environment but rather to show how to build a system which can help you as the student, understand the possibilities both good and bad.
|
||||
|
||||
### Step one:
|
||||
|
||||
|
@ -182,11 +182,11 @@ There is also a try/catch portion of each step, that reviews the output of the s
|
|||
|
||||
Step 1:
|
||||
|
||||
### In the above Step function, decide how you want to do first.
|
||||
### In the above Step function, decide what you want to do first.
|
||||
|
||||
### **Breadcrumbs**
|
||||
|
||||
As stated above, maybe we should take care of the account breach first. There is a way to do that in an automatically.
|
||||
As stated above, maybe we should take care of the account breach first. There is a way to do that automatically.
|
||||
|
||||
Review:
|
||||
|
||||
|
@ -218,11 +218,10 @@ def lambda\_handler(event, context):
|
|||
|
||||
Step 2.
|
||||
|
||||
Work through the need for a networking change. In a datacenter this could take a significant amount of time. This will be much quicker. How do we correct the Security Group? We use a similar Lambda function to that.
|
||||
Work through the rquired SSH networking change. In a datacenter this could take a significant amount of time. This will be much quicker. How do we correct the Security Group? We use a similar Lambda function to that.
|
||||
|
||||
### **Breadcrumbs**
|
||||
|
||||
As stated above, maybe we should take care of the account breach first. There is a way to do that in an automatically.
|
||||
|
||||
Review:
|
||||
|
||||
|
@ -308,11 +307,11 @@ def lambda\_handler(event, context):
|
|||
|
||||
Step 3.
|
||||
|
||||
Once you have built and tested the two above Lambda functions. Once those functions are running you will need to incorporate them into the above Step Function in your lab. This part should be straight forward.
|
||||
Once those functions are built and tested, you will need to incorporate them into the above Step Function in your lab. This part should be straight forward.
|
||||
|
||||
Step 4.
|
||||
|
||||
To test this step function, you need to fire it in some way. The best way to test this is add a cloud watch rule.
|
||||
To test this step function, you need to trigger it in some way. The best way to test this is add a cloud watch event.
|
||||
|
||||
|
||||
|
||||
|
|
Загрузка…
Ссылка в новой задаче