Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to dig deeper into systems, stay embedded even after detected, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show that the time to detect a breach is over 200 days and is typically detected by external parties rather than internal logging or monitoring.
-
0:00
The final vulnerability we will cover in this course is new to the OS top ten
-
0:04
in 2017, insufficient logging and monitoring.
-
0:07
Insufficient logging, detection and
-
0:10
monitoring of applications occurs anytime important events such as logins,
-
0:14
failed logins, and critical transactions are not logged.
-
0:18
It also occurs when logs of applications and APIs are not monitored for
-
0:22
suspicious activities.
-
0:24
Which could include users performing actions they don't normally do, or
-
0:27
using too many resources.
-
0:29
Or it could include logins from users that don't often occur.
-
0:33
Furthermore, when alerts are not triggered when critical or unusual actions occur,
-
0:37
developers and system admins can miss out on major security incidents.
-
0:42
As a developer, it doesn't matter if you have the most secure code and
-
0:45
follow all the right best practices if you fail to keep logs.
-
0:48
If you have no ways to gather information about the usage of your application,
-
0:52
you'll be in the dark when a major flaw is discovered and exploited.
-
0:56
By capturing all necessary information during application deployment, usage and
-
1:01
downtime, developers and
-
1:03
system admins know where to look when incidents do occur.
-
1:06
Addressing this new vulnerability is fairly straight forward, but
-
1:09
can be difficult in practice.
-
1:10
Regardless, it is worth doing.
-
1:12
To prevent not having all the information you need during security incidence,
-
1:16
developer should be recording logins, access control failures and
-
1:20
input validation failures.
-
1:22
Each of these should be captured along with the additional data necessary to make
-
1:25
sense of it, like the user in question and the time of failure.
-
1:28
Capturing high value transactions is also critical, from payments to file downloads.
-
1:33
These types of transactions represent potential areas where an application can
-
1:36
be breached, and negatively affect innocent users.
-
1:40
No matter what, when logging information in an application,
-
1:43
never log user credentials and user sensitive information.
-
1:46
This includes passwords, specific debit or
-
1:49
credit card numbers whenever possible, social security numbers,
-
1:52
healthcare records, and personally identifiable information.
-
1:56
This information should only be store hashed, or encrypted in a database or
-
2:00
other secure storage mechanism, if stored at all.
-
2:02
Finally, developers and
-
2:04
system admin should have an incident response plan in place,
-
2:07
which covers what the application owners will do if the application is breached.
-
2:10
These plans cover how to contain a spread of an attacker, and
-
2:13
what to put in place next time to ensure the breach does not occur again.
-
2:17
To get a sense of building an incident response plan,
-
2:19
the US National Institute of Standards and Technology, better known as NIST,
-
2:23
has a guide to handling incidents which is linked in the teacher's notes.
-
2:27
That wraps up insufficient logging and monitoring.
-
2:29
In the next and final video, we'll look at the next steps you can take
-
2:32
to becoming an even more proficient application security expert.
You need to sign up for Treehouse in order to download course files.
Sign up