A common technique when building web applications is to hide menus based on the user logged in. While it is obscure, it certainly is not secure. Each script must have access control built in. I prefer to delineate roles and map users to them. When a page is requested by the web server, check the logged in user name against the map. Don’t forget about your include files. Scripts that are included by others should have access control as well.
Obscurity is actually a good thing; the less info an attacker has the better. It just can’t be considered security.
Here’s a linear expansion of three articles that caught my interest: The first from Andy, ITGuy (Did complacency kill the cat or was the cat already wounded) refers to a post from The Daily Incite (Complacency killed the cat) which comments on a Small Biz Resource article (Report: SMBs Overconfident on Security).
I’ve worked inside small business, then enterprises, then consultant to large enterprise, and now consultant to SMBs. Frankly I prefer to work with small clients most of the time, but one of the big challenges is education. A large part of my job is educating the client so that we can then implement. It’s both a pleasure and a pain to do.
So, what’s education got to do with it? In many cases I think the complacency that’s being seen is really coming from ignorance. If a business owner / manager clearly understands the gravity of a situation they will be less likely to see roses everywhere they look. If, like most small businesses I’ve worked with, their #1 concern is just keeping it running, they feel success when they reach a state of system or network maintenance. When those same folks learn enough to understand the types, severity, and frequency of threats they face, they will be more likely to engage and work to improve their security. With that understanding, a simple firewall and AV deployment will turn from being seen as Fort Knox to my kids’ pillow fort.
Part of network security is to cover all the bases, including the software used to run your business. Your network can have every security measure known to man, but if your software has holes, you’re sunk.
The base two categories to look at are internal and external threats. Internal threats are employees that are looking to steal your contacts/data. External threats could be a fired employee, a virus, a hacker, or some bored 15 year old latch key script kiddie.
Internal threats are handled by designating roles. To help illustrate, let’s look at an object oriented design called “document/view”. The document holds the raw data, and the view reveals a portion of the data. For example, a salesperson view would hold the data for one customer, with their invoices and payment history. A sales manager view would group the raw data into a quarterly sales report. Each view corresponds to a role.
Traditionally, applications would denote the roles as “Salesperson” and “Sales Manager”. However, that doesn’t fit well for small and medium businesses. I prefer a more granular approach. You could still have the salesperson role, but the quarterly sales report would actually be “Quarterly Sales Report”. This allows you to give that role to the top 3 salespeople that have been with you for years (and more than likely are related to you).
External threats can be physical or virtual. Physical access is obvious to address (deadbolts, pit bull with aids, etc). Virtual access is more tricky. A few pointers:
Cleanse any data coming directly from a shopping cart, registration page, or other external source.
Don’t have one login/password to login to the system. Have a password maintenance policy.
Review your logs.
Use anti-virus/email filtering service.
Develop a data retention policy.
Make sure your data backup is secure.
Finally, use software that conforms to your business. If software changes your roles, it could lead to employees having data you’d rather not reveal. After all, it’s your business.
In Alex Bakman’s recent post he says “It’s time to let your actions show just how committed you really are to securing your infrastructure”.
Time to come clean… I can’t remember not using my current “strong” password, and my online passwords wouldn’t be considered very strong!
Charles and I are quick to tell people that security is not convenient. Well, it’s time for me to be inconvenienced and develop some new strong passwords, put them to use, and devise a password changing policy for myself.