FISMA Security Monitoring Review Templates
1. IT Security Risk Identification
- What IT services are being provided to the organization related to cyber security or FISMA compliance (e.g., externally facing Internet systems, systems that have personally identifiable information (PII), etc.)?
- What are the organizational and IT units, and how are they managed (e.g., the centralized IT services group, an IT outsourcer, etc.)?
- What are the other relevant regulatory and contractual requirements for the organization process (e.g., HIPAA, NERC, interagency agreements, contractual service level agreements, the Freedom of Information Act (FOIA), etc.)?
- What technologies and IT processes are being used for an in-scope asset (e.g., Microsoft Windows Server, Sun Solaris, Oracle, Microsoft SQL Server, etc.)?
- Are there any high-level risk indicators from the past to be aware of (e.g., repeat audit findings, frequent outages, etc.)
2. Monitor Power User Access
- Document all administrators with privileged access and ensure we can reconcile them with authorized staff. Disable or delete any ghost accounts that cannot be reconciled to authorized staff.
- Work with system managers to reduce the number of administrators to the practical minimum needed.
- Ensure that access is appropriately revoked or assigned in response to personnel turnover or transfers. To ensure the measures listed above reduce privileged access, we must:
- Monitor privileged user account adds, removes and changes wherever they are stored, including service accounts that do system maintenance and tasks such as backing up accounts and managing the enterprise batch scheduler.
- Reconcile each privileged user account add, remove and change with an authorized change order from the relevant manager. This reconciliation process may be manual (a signed paper form) or automated (with a change ticket from a change management system).
- Reconcile each privileged account with an authorized user. For example, reconcile the account with an HR record. Alternatively, reconcile each account with an authorized service such as a backup program.
- Routinely re-accredit accounts—quarterly or yearly, depending on turnover—to ensure that management can reconcile privileged accounts to reports from HR and payroll.
3. Configuration and Standards
- Work with IT management and relevant managers on a policy that defines which security standard or standards should be used.
- Mandate that all production technologies that pose a risk to cyber security or FISMA related objectives use these secure configuration settings, and create a plan for deploying technologies with these settings.
- Define a time limit for initial implementation, and set expectations for how quickly corrective measures must be taken on non-compliant configurations. To ensure the above configuration controls are implemented correctly, we must:
- Assess and continuously monitor configuration settings. For example, we may need to assess and monitor settings stored in Unix or Windows files or Windows registry settings.
- Test configuration settings against internal security policies, external compliance requirements and industry best practices. Report on any variances.
- Verify that corrective actions to non-compliant configurations are properly implemented in the required time frame.
4. Change Management Processes
- Help assess the potential impact of changes on information security and operations.
- Improve procedures for change authorization, scheduling, implementation and substantiation.
- Ensure that change requests comply with information security requirements, corporate policy and industry standards
5. Trusted Server Build
- Develop standards that specify how to secure and harden the builds we release into production or check into the definitive software library (DSL). For guidance, we turn to configuration standards for information security developed by trusted external organizations such as CIS, the SANS Institute, and IT system vendors. As these external standards evolve, we’ll need to update our documentation.
- Work with the server provisioning and release management teams to integrate independent configuration standards and checklists. We’ll also need to take standard risk-reducing measures, such as:
- Turnoff unnecessary features and modules that are enabled by default
- Disable un-needed services (e.g., http, DNS, and SMB)
- Disable un-needed open network ports
- Delete or disable unnecessary user accounts
- Change default passwords
- Ensure that relevant passwords are changed before systems move from development to production—for example, developers who know ODBC and application passwords for a new order entry system no longer need these passwords when the system enters production.
- Include standard configuration monitoring agents in each trusted build.
- Assessing production configurations against known internal and external standards to ensure they are in a known, approved and secure state.
- Monitoring the approved build library to ensure that all adds, removes and changes conform to internal and external standards.
- Reconciling all adds, removes, and changes to an authorized change order. This task may be done manually or may be
6. Release Management Procedures
- Develop templates for release management and interface with this team as well as quality assurance (QA) and project management to ensure that information security and regulatory compliance requirements are methodically collected at the start of each project.
- Establish an agreed-upon protocol for when and how release management should engage information security. For example, an agreed-upon protocol should be established regarding releases that include code that involve authorization, encryption, financial transactions and compliance requirements.
- Integrate automated security testing tools into the release testing process and run them against code, builds and releases. Use vulnerability scanning and management testing tools, even if they could potentially crash applications during testing—it’s better to find vulnerabilities in pre-production rather than in production. Use the same tools in the preproduction and production environments to prepare IT operations for potential problems when these tools are used in the production environment.
- Compare releases and approved builds being deployed against known and trusted states to mitigate the risks introduced by human error, missed steps, mis-configurations and other sources.
7. Production Activities Change Management
- Under what conditions are activations, deactivations and restarts changes that require approval? Consider, for example, whether changes require approval if the change delivers a new IT service, enables a service that has security or regulatory requirements, or introduces outage risk to a missioncritical service.
- Who must approve standard and emergency changes?
|Free Download Attachment||Size|