So lets start looking at System i security using the following method: First, float above the clouds and figure out what we need; next, land and find out what we need to do; then, go into the heart of the darkness and look at how we're going to accomplish it. Thus we can accomplish the task of developing a security policy in the least amount of time, and take advantage of our lazy programmer skills. In the next two articles we'll land -- plan our strategy, and we'll dig into the system, get our hands dirty and make the appropriate updates to secure our environment!
Helicopter view of System i security
We first need to we look down on what we need to accomplish, and decide how we're going to protect our computing environment. Viewed this way, we see what we want to protect: our workplace, the systems within them, and the people that are using them. Where do we begin? First, create a security policy for the corporation. This would cover:
- Securing your computer
- Securing your files
- Keeping your password(s) safe
- Securing the area you work in
- Securing you data center
- Securing the people within your organization
- Securing your internet connection
When a person is hired by your company, the security policy must be disseminated to so that he/she understands their new work environment and responsibilities. Also, this reinforces their place in the security process. All security configurations are moot unless the consequences about the employees actions and inactions are on paper. Your organization can be compromised by many things -- very few having to do with the configuration of your computers. Internet policies and "work email" usage and misusage need to be understood so everyone understands that this is an office -- all personal business needs to stay home as much as humanely possible.
What is the security of your building? Do you have a fence around the perimeter? Alarms? Do you have limited entry and exits that are monitored? In higher security environments -- banks, government facilities, and the like -- do you have name badges identifying individuals and the limits of their access to your facility? A simple low-tech solution is to make sure people are in the right place (at the right time) by having different colors behind the photo in the ID badges. Without getting too creative, when the person is hired, the name badge with their department color code is behind their head when they have their picture taken. Now the face and the color (and something on their badge) says where they have access to. The key is to train everyone about what these colors are -- communications is critical to security.
The best example I can give of an access security issue was when I bumped into someone after hours in the company I was working for. The individual was buying candy, and discovered that she had locked herself out of the secured portion of our company, so she asked me to let her back in. Here was my dilemma: Nobody was upstairs to let her back up, the portion of the company had millions of dollars of product and computers sitting in it, and it was after hours. She could get injured on the premises and nobody would know until someone returned to work the next day. So, I apologized, asked if she was working with someone upstairs. She said "no," she was in a conference room working alone. That was all I needed to hear. So, I left her in the lunch room, grabbed my things (time to go home) helped her pack up her things and escorted her to her car. Turns out she was an auditor -- and we got rather high marks. This was the "Stranger Danger" approach -- why?
- She had access to an area as a guest she shouldn't have had without an escort within the company
- She could have been injured on premises
- She could have compromised many portions of the company that could have cost a lot of money
Lets briefly talk about your datacenter. Is this portion of your company protected by a code key? Badge security? Better question, is everyone trained in your company to stop when someone asks "Where's the Data Center?" or "Where is the IT Department?" and say "We'll have someone meet you and escort you." Guests should never be allowed to walk on their own to the Computer Center -- they should always have an escort. Also, remove all signage leading to the data center. Back in the 1970's the quickest way people would disable a company is by destroying their expensive computers -- how'd they find them? Why convenient signage. "This way to the Datacenter!". Your computers should be the most secured portion of your company. Today, the computer center has many many computers waiting for deployment so the same lack of signage helps in today's environment.
How about your passwords, and how your company treats them? Can an employee write them down? Are there deadlines where the passwords will change monthly or quarterly? Is there a written policy about how employees must treat their passwords -- for instance can they share them with colleagues? How about outside people in the company -- what are the consequences to giving out their password to someone that doesn't work for your company? These eventually are to drive home how important it is to memorize, and to be responsible for the access given to them. If they forget their password, and need it reset, could it be a warning placed on their permanent record with the company?
The key to IT security is communications. Letting people know that "it is wrong" to do certain things. As humans, people usually want to be helpful, and their instincts don't tell them how to keep the IT department secure. That's why we develop policies.
Getting your environment prepared for security is as simple as
- Communicating policy to all employees
- Making sure everyone is identified as secured for the environment they are in
- If they do not have the appropriate security, they need to be escorted properly. A temp shouldn't be wandering around your building, ever
- Making sure your computers are secured within this environment.
The prerequisites are the people and the communications. Next time -- we land!
ABOUT THE AUTHOR: Andrew Borts is webmaster at United Auto Insurance Group in North Miami, Fla. He is a frequent speaker at COMMON and is past president of The Southern National Users Group, an iSeries-AS/400 user group based in Deerfield Beach, Fla.