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