Systems within the headquarters’ enterprise Active Directory domain are not fully compliant with the department’s security guidelines, and no mechanism is in place to ensure their level of security. These systems were added to the headquarters domain, from trusted components, before their security configurations were validated. Allowing systems with existing security vulnerabilities into the headquarters domain puts department data at risk of unauthorized access, removal, or destruction.Some of the specific issues called out include:
Also, the department does not have a policy to verify the quality of security configuration on component systems that connect to headquarters. Interconnection security agreements are present for each connection between headquarters and components to secure shared services; however, neither the agreements nor other policy define specific security controls required for connecting systems. Stronger management and technical controls are needed on trusted systems to protect data provided by the department’s enterprise-wide applications.
- A default privileged account enabled on a Windows server
- Missing security patches
- Local password policy not set to DHS standards
- A protocol in use that is specifically identified in DHS policy as vulnerable
This report illustrates how difficult it is to enforce a consistent security policy. Yes, there are built-in tools like Group Policy and commercial tools that would help DHS enforce security policy. Yes, you can have written policies. However, at the end of the day, reports like this help to define areas to focus on.
Read the report. Do you have any of the problems that were highlighted? How are you remediating them, or are you?
Technorati Tags: identity management,Active Directory,compliance,security
No comments:
Post a Comment