We’ve grown accustomed to reacting to familiar events. It’s easy to fall into old habits despite the ever-changing digital landscape. I’ve often said, “there’s nothing new under the sun,” even though that’s not true. Artificial Intelligence (AI) has existed for decades but has only recently caught the public’s eye. At one point, AI was new. Large Language Models (LLMs) were new. Everything, at some point, was new.
There are new ways of securing our environment, fancy tools, and shiny processes. But are we missing the mark by chasing the latest, greatest, and easiest solutions? Over the years, speaking with people at conferences and peers, I believe we have. Here are some foundational methods and tools in Information Security worth a fresh look.
Audit Logs
I sense a collective shudder, but hear me out. In a Splunk session, the presenter asked what we’d do if our SIEM went down during a critical incident. The 50 or so attendees were lost. We rely on technology to make our lives easier, forgetting our roots. Am I suggesting ditching your SIEM and rolling up your sleeves? No! But manual log review is a skill worth practicing and teaching. Non-error logs can offer great insights into what was happening around the time of an issue. While not the most critical item, it’s an important skill. What would you do if your SIEM failed and you had to address a critical event?
Role Based Access Control (RBAC)
Most people I talk to will confidently say they have RBAC implemented. ServiceNow, Active Directory, Azure, etc all has RBAC built in and that is what the collective majority will point to when asked about RBAC. Having implemented it in that fashion is just the beginning though and really too cumbersome to manage at scale. Not only that but you run the risk of permission creep when a user changes roles and needs less permissions or at the very least, different permissions. The human factor rolls up and the over worked end user support team just gives them the access they are looking for or a manager says “just give them my permissions.” I have seen it for years across government and commercial organizations alike.
So how do we fix it? The answer is almost guaranteed to be in your environment already, Active Directory. Every leg in your organization has a set of permissions and files they need access to. Taking an inventory of what those permissions are, you can create security groups for the specific roles/titles/job descriptions (call it what you want) and then tie access to directories, application, entitlements, etc to those job descriptions. When an employee gets promoted, demoted, or changes department, it is just a single move to pull the employee out of their old security group into the new one and all of their permissions are automatically changed. This takes a bit to set up, but once it is, it is a breeze for everyone to administer, audit, and monitor.
Network Diagrams
Ever try to build Ikea furniture without the instructions? That’s kind of like trying to build out a network without sitting down and mapping out everything you need before hand. Just like the Ikea instructions, a network diagram shows you all the parts of the network and how they work together. This can be a great tool when diagnosing network issues and making sure you have your VLANs and network segmentation configured properly. Keep in mind that this shouldn’t just document your physical network, but it should include any cloud infrastructure and services as well. Outlining how services reach and talk within your environment makes it easier to know where to sever a connection if needed in an emergency. Making sure your network diagram is updated frequently is also going make your compliance team happy with you come audit season.
Network Segmentation
This is something that a surprising number of people don’t understand or struggle grasping the concept. The fifty thousand foot description of this is that you want to prevent sections of your network from talking to other sections of your network. There are seemingly infinite reasons why you would want to do this, but the most common is to prevent your sub-production talking to your production environment. Often times the sub-prod environment won’t have as stringent security controls around them for testing purposes or may have less than ideal configurations to solve problems or any number of things. Because of that, you don’t want those environments touching your production data which would increase the risk of loss. Even if you don’t host customer data, you will absolutely have PII, sensitive and critical business data, and any host of other information depending on your organization. Another reason for network segmentation could be department separation. You may not want HR or finance systems accessible to everyone in the organization and network segmentation is one way protecting those assets and data.
This is just scratching the surface of lost methods and tools that is sitting there waiting to be used. I challenge you to take my thoughts and see where you might be able to improve. It’s so easy to get caught up in the latest tools and talking points, but it is all for naught if we aren’t taking care of the fundamentals of security. Let me know your thoughts. Am I off base? Is there something else you see that is often forgot? I look forward to hearing your comments.
Comments
One response to “Return to the Basics of Security”
Great job on the article and thank you for the information, Russel! I personally gravitated towards the read because it was enjoyable to follow and felt as if I was having a conversation opposed to reading a report.