Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 87

In all cases, you should first have an administrative (people-facing) control document, such as a policy statement or a procedure, that provides the justification and the details you need to configure, operate, inspect, and update all of the technical settings that implement the electronic aspects of your security architecture. These include both the networks, servers, and endpoint technologies, such as software Group Policy Objects, parameter files, access control lists, or even jumper and patch panel settings. Also included are the programming, options, and controls for fire and safety alarm systems, motion detectors, entryway alarms, power conditioning, and environmental control systems. (Remember, it was through a maintenance back door in the heating, ventilation, and air conditioning systems that attackers were able to gain entry into Target's systems in 2013.)

Two of the most common technical controls used in many security strategies are related to setting time limits on user activity. Session timeouts or inactivity lockouts can be implemented on an endpoint device level, on a per-user ID level, or by individual applications platforms, servers, or systems. They force a user to take a positive action to reconnect or renew a login (and go through some or all authentication factor steps) to continue, once their device, session, or use of that resource has been inactive for a specified period of time. This can be frustrating to users when they've come into a system via SSO authentication, gaining initial access to a set of resources and applications at the start of their workday but then having to repeatedly log back in again when they've let individual sessions with specific apps or servers go idle for too long. Session timeouts provide protection against the “lunchtime attack,” which got its name from an intruder being able to wander around an office building and find computers unattended but still logged into the system during lunch breaks. Device-level timeouts on company-managed endpoints are typically set for short periods, such as 10 minutes, based on similar reasoning. Specific applications platforms and the portals that your users access them through may need to impose their own timeout periods and choose whether to use timeout warning reminders, based on specific systems security needs.

Another time-based technical control, the merits of which are hotly debated, is password aging; this sets a time period (usually measured in days, not minutes) after which a user must change their password. Other password policy settings can limit password reuse as well. Password aging, length, complexity, or other password characteristics should be determined as part of your integrated approach to identity management and access control; proper implementation of multifactor authentication, for example, may provide greater security and ease of use than complex, rapidly aging passwords were once thought to provide.

All of these settings should be subject to formal configuration management and control and documented in some fashion so that an incident response team, network operations staff, or the IT team can quickly refer to them to determine whether the alarms are sounding due to a misconfigured control or because a security incident is occurring.