Security Brain Dump – Part 1 of 3
From numerous security discussions, below is a rapid brain dump of elements to look out for when implementing separation of duties (SOD) along with multi-factor authentication.
When tackling security, a bit of forethought and planning is required prior to wondering head first into these particular wastelands. Like anything, security certainly requires understanding of the scene to best plot a course.
Some mistakenly think security is a one shot deal (‘wham bam, thank you ma’am), then cast it aside like a dirty shirt. Similar to dieting and fitness, there isn’t a panacea. Security requires constant alertness. It requires an alignment of solutions to meet or reach your goal. Security practices are laid in systematically through observation, planning and design, along with routine review for efficacy.
Recommendations:
A well laid out and simple MFA solution needs to embrace and properly align with actionable rules with, of course, practical and enforceable standards. Coupled with an SOD solution, you have in your hands the ability to significantly improve a business’s security posture.
For ‘Human accounts’ (those used by people), start simple. Later, you’ll likely find service accounts align into a similar design. Without going overboard, begin with a definition or model of your business administrative duties or roles. Boil this down to a few categories (see examples below). Above all, don’t let this become a run away train. Avoid getting into a drawn out figure-figure. Trust me, once you have implemented version 1 of your design (and your feet are wet), there will be plenty of opportunities to expand to meet further standards. Your initial goal is to keep this fairly simple, get it implemented and see where it goes.
Your audience are those who will be adopting your design. Be kind but consistent. Above all else, don’t become lax or reasonable if the waters get choppy – believe me, they will. Encourage feedback.
Administrative duties typically break-out into three to four possible layers of differing accounts, with stress placed on the type of access required or duties (verbs). Beware of the difference between privileged access (verbs) and sensitive data (nouns). This does not address management or access to sensitive data (typically controlled via ACLs or permissions).
- Highly Privileged Accounts – these maintain or provide the highest administrative duties over critical systems used throughout your infrastructure (such as Active Directory). Highly Privileged accounts should be VERY SMALL IN NUMBER and limited only to trusted officers. This would not include access to lower tier systems or functions, such as databases, password changes, etc.. Highly Privileged account IDs ought reflect their usage: e.g. EA-JMoss or !JMoss (something that makes them different from other accounts). These account would NEVER be used to log into and manage lower tier systems, such as servers, workstations, appliances, etc.. Tight controls should be defined, implemented and maintained for usage and access, such as: quarterly reviews, enforcement and stringent password policies, multi-factor authenication, monitoring, etc.
- Privileged Admin Accounts – excluding critical systems, these type of accounts maintain or provided administrative duties or controls over all remaining systems. These account types would NEVER be a member of Domain Admins. These account IDs should also reflect their usage: e.g. A-JMoss
- Standard User Accounts – these are your standard IDs used to access resources (such as mailboxes, skype, etc.) maintaining zero elevated privileges. If needed, VPN would be enabled for these account types.
Digressing slightly; it is recommended to proactively identify opportunities to implement reasonable controls (and precautions) governing ‘shared’ accounts. Far too often, businesses implement governance for these far after having gotten ridiculously out of control requiring costly and lengthy remediation efforts – Yikes.
