Story # 2 “How due to laziness a security audit was failed” (from “5 stories about information security”)
We continue a series of posts in which we talk about problems that an IT specialist may encounter in the absence of suitable tools for monitoring and auditing changes in various IT infrastructure platforms.
The first story ("The Midday Thief") you can read here.
And now the second story, “ How did a security audit fail because of laziness, or who changed the group policies? ".
')
“We failed the security audit!”
Chief Jennifer was furious. And it could be understood: they had just failed an audit, and what is most offensive, because of a mere trifle. Instead of a strict domain password policy, auditors found that it was completely disabled. For a while, the user passwords did not expire. Now it is already fixed (it is not so difficult to do it), however, the reverse side was revealed. Users began to call the support service en masse, since they all simultaneously expired passwords. However, this was not what worried the boss.
"Who did this?!!"
Jennifer looked at her colleagues. The company had more than 20 members of the Privileged Domain Administrators group, and any of them could have turned off the password policy. The password policy was set in the high-level group policy object, which contained thousands of other settings. All of these administrators made changes to group policies almost every week. Access logs were displayed in the event logs, but the audit logs did not contain information about which settings were changed. Anyone could do it — even by chance — and there was no way to determine who it was. Joseph, a new administrator, nervously explained this to his boss, who was clearly not satisfied with this situation.
“That is, someone either accidentally or specifically changed these settings, and we cannot find out who it was exactly?”
Everyone nodded together. Even if the security logs were archived, few people would like to dig and search for information in all the records for the previous month in more than 20 domains. And besides, the log records did not contain the necessary information.
“No one wants to admit?” Asked the boss. No one confessed. Over the previous 4 months, 4 administrators left the company, and the easiest thing was to shift the blame on them.
“Does anyone have any idea why this was done, if it is not an accident?”
Jennifer shrugged. “I think they are confronted with a user who could not come up with a fairly complex password. Everything was easier to disable the policy. Some of us did this before, to quickly give access to the network, and then immediately turned on the policy. Maybe someone just forgot to include the policy. ”
“Not at all what he would like to hear,” thought Jennifer, seeing the superior's face turn purple with anger.
She knew that her company needed a better solution for auditing changes, especially those related to group policy objects. Need to know who and when they changed. And you also need a solution that would allow you to optimally store log records so that you can immediately filter only the records of changes to GPOs, preferably without a separate search for each domain controller.
What solutions would you use to monitor group policy changes?
The first story ("The Midday Thief") you can read here.
And now the second story, “ How did a security audit fail because of laziness, or who changed the group policies? ".
')
“We failed the security audit!”
Chief Jennifer was furious. And it could be understood: they had just failed an audit, and what is most offensive, because of a mere trifle. Instead of a strict domain password policy, auditors found that it was completely disabled. For a while, the user passwords did not expire. Now it is already fixed (it is not so difficult to do it), however, the reverse side was revealed. Users began to call the support service en masse, since they all simultaneously expired passwords. However, this was not what worried the boss.
"Who did this?!!"
Jennifer looked at her colleagues. The company had more than 20 members of the Privileged Domain Administrators group, and any of them could have turned off the password policy. The password policy was set in the high-level group policy object, which contained thousands of other settings. All of these administrators made changes to group policies almost every week. Access logs were displayed in the event logs, but the audit logs did not contain information about which settings were changed. Anyone could do it — even by chance — and there was no way to determine who it was. Joseph, a new administrator, nervously explained this to his boss, who was clearly not satisfied with this situation.
“That is, someone either accidentally or specifically changed these settings, and we cannot find out who it was exactly?”
Everyone nodded together. Even if the security logs were archived, few people would like to dig and search for information in all the records for the previous month in more than 20 domains. And besides, the log records did not contain the necessary information.
“No one wants to admit?” Asked the boss. No one confessed. Over the previous 4 months, 4 administrators left the company, and the easiest thing was to shift the blame on them.
“Does anyone have any idea why this was done, if it is not an accident?”
Jennifer shrugged. “I think they are confronted with a user who could not come up with a fairly complex password. Everything was easier to disable the policy. Some of us did this before, to quickly give access to the network, and then immediately turned on the policy. Maybe someone just forgot to include the policy. ”
“Not at all what he would like to hear,” thought Jennifer, seeing the superior's face turn purple with anger.
She knew that her company needed a better solution for auditing changes, especially those related to group policy objects. Need to know who and when they changed. And you also need a solution that would allow you to optimally store log records so that you can immediately filter only the records of changes to GPOs, preferably without a separate search for each domain controller.
What solutions would you use to monitor group policy changes?
Source: https://habr.com/ru/post/141389/
All Articles