CAREFUL, THEY MIGHT HEAR YOU
word “auditor”, of course, comes from the Latin audire
'to hear', since audits were originally presented orally. Hearing is
the auditors' profession, so there's no need to shout at them. If you say your system is secure, they're listening.
Security is your business
Many administrators see security as a burden, an obstruction to their work ... until there's a real violation. Your company, and your job depend on keeping the bad guys out (and I don't mean the auditors). It isn't just malicious attacks which can compromise your systems and even wreck your business. Security is also about stopping innocent parties from doing something dangerous without meaning to do damage. By the way, those "innocent" parties might just include you, pal.
Call in the aixpert
There are so many components to system security that it's hard to keep up with them. So the nice people at IBM did us a favour and wrapped it all up into a single command that at the same time makes you feel important: aixpert (not to be confused with the excellent AIXpert Blog). Having over 300 security settings in a single command should make your job easier. Still, you need to be careful. As I explained to a manager recently: "I can secure your operating system and break your business in a single command."
Don't do it yourself
Unless you're only managing a single LPAR, it's simply mad to script or configure all the settings one by one. Use the aixpert command. That's what it was written for. There is some very helpful documentation explaining why and how to run aixpert, including:
- man pages for aixpert command
- IBM Wiki movie 54: System Hardening with aixpert
- aixpert - Hints & Tips wiki
- Ken Milberg's developerWorks article Using AIX Security Expert
- AIX V6 Security Features Redbook
- AIX Virtual User Group Webinar: October 29, 2009 - AIX Security presented by Bhargavi Reddy
Interface to the expert
You can configure aixpert security settings for an LPAR
- via the command line
- IBM Systems Director (pConsole) (see IBM Wiki Movie 13)
- using SMIT (known as smitty to his friends), but that is only for a lock-up-the-lot-of-'em no-exceptions approach to security.
If you want to see each rule in detail and are not keen on editing XML files, WebSM provides a more granular view than the other interfaces. WebSM allows you to select or deselect a rule in a menu with common rules grouped together (e.g. Password Policy, Login Policy, Tuning Network Settings). To use WebSM you will need to set up an X-Session. The recommended way, though, is by running aixpert on the command line. You can do this in conjunction with XML files provided for the AIX Security Expert.
XML for aixpert
ALL available aixpert settings which you can choose from are in the file /etc/security/aixpert/core/aixpertall.xml This file includes the level of security you have selected, a description of each of the rules and the actual commands which are run for each rule.
All the settings you last applied via aixpert are saved into an XML file called /etc/security/aixpert/core/appliedaixpert.xml
If you choose a security level (high / medium / low or default, which is lower than low), then only those rules for that level will be applied. (Each rule name starts with a three-character prefix i.e. hls= high level security, mls = medium, lls = low, dls = default). You could then create a set of these rules (e.g. high level), save it to an XML file and then strip out or tailor that list of rules for your system. You can also run a check on your appliedaixpert.xml file (if it exists) to see which security rules fail to comply. These would be the rules you either want to fix or explain to the auditors why they are not applicable for your environment.
XML for smarties
Having all your settings in a single XML file allows you to edit the file, view it in a spreadsheet or XML editor, and distribute the same rules to other LPARs and apply them using aixpert -f filename.xml. This also enables you to retain a history of XML files, provided you save them off to some other file name or back them up. It's a smart way of doing it.
Although the aixpert tool is undoubtedly helpful, here are some initial findings which I have yet to confirm, but which are worth being aware of as potential problems.
- there is no XML snapshot of the system's current settings if you have made changes without using aixpert. If you did use aixpert, the new settings should be in appliedaixpert.xml
- you may want to apply default level security before applying any higher security levels from your XML file. This provides you with some sort of baseline.
- The undo option doesn't seem to roll back recursively. It looks to save only one previous version of the security settings.
- WebSM only displays all available settings (from aixpertall.xml). It doesn't show you which of the settings you have actually changed.
- You can't see what your current security level is set to except via WebSM (or try fpm -s)
- If you want to get very granular, turning off lots of rules, it's hard work and you need to explain the rules you have disabled to the auditors.
- Migration and patching overwrites your security settings according to that Webinar linked to above. After moving to a new version of AIX you would need to apply the previous settings again using the aixpert -f option and the XML file which should have been saved off as part of the AIX upgrade.
- Setting SOX-CORBIT level doesn't include settings which are already covered by High security.
With all those difficulties, is it still worth using aixpert? Yes, I would say so. Each of the warnings has a simple enough workaround , and saving XML files as you go is usually it. The question is not whether aixpert is worth the trouble. It's whether not using it is worth the risk. Don't tell me your system is secure; tell the auditors. They're paid to listen.