|Modern Middle Manager
Primarily my musings on the practical application of technology and management principles at a financial services company.
It's What's Inside That Counts
Saturday, January 25, 2003 Phillip Windley, ex-CIO of the state of Utah, blogged a brief post about securing your network from the inside. He brings up five major points from his perspective as a manager of developers:
1. Limiting access to production servers.
2. Create activity logs and audit access.
3. Secure monitored data away from developers.
4. Hire carefully doing background checks.
5. Regulate hours.
In a small shop with two developers who also play some systems roles, how can I create a similarly secure environment? To limit access to production servers creates a greater burden on my systems staff who have enough to do so that point is compromised. Hiring carefully we do to some extent; being a fiduciary we fingerprint all employees and run them through California's felony database. Hours are regulated for most non-IS staff. However, for the IS staff I believe in cross-training everyone so an emergency in the wee hours can be handled by more than 1 or 2 members of my staff. So for me that means concentrating on point #2 and #3.
Activity logs and auditing access to sensitive data means doing two things: determining what classification data has (top secret down to unclassified, as per the CISSP Handbook), securing access appropriately and combing auditing logs, preferably automatically. No one wants to wade through audit logs and some simple Perl scripts should be able to alert me to something unusual. Of course that means I either have to roll the code myself or review the source written by my developers but it's a small shop and easily done.
Securing monitored data away from developers is more difficult because our management begs the IS department to create any number of reports, usually dealing with that selfsame secure data. How should I then keep the developers out of that information? One way is to restrict access to the read-write version of the database, extracting data to a read-only datamart or data warehouse. As we build our first data warehouse this year to track our product profitability, we'll be migrating our reports to point to the warehouse and/or its attendant marts. Another problem is that developers may surreptitiously leak confidential information to others in or out of the company. With a small department it's not that hard to figure out who that may be. On a larger scale it would probably require me partitioning access to various data between various developers, much like granting clearances in the defense industry.
posted by Henry Jenkins | 1/25/2003 11:45:00 AM
Comments: Post a Comment