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