Here is your iSeries security tip for February, 2007 from SkyView
Partners, Inc., World Class i5/OS and OS/400 Security Experts.
You may have seen the term, "security best practices" in
advertisements or in articles. But what does it really mean and how
does it apply to you? Let me try to clear up the confusion.
Security best practices are a set of guidelines that security professionals
recommend for securing your system, network or database. These guidelines
are recommended settings that, when implemented properly, provide
a system or network that provide the best defense against hackers
or inappropriate access to data.
What does it mean to me?
View security best practices as a set of guidelines. Review them
and configure your system as close as possible to the recommended
settings. Implementing these recommendations will not only provide
a secure system or database, but will also significantly increase
your organization's chances of passing audits, complying with current
laws and regulations as well as being prepared for future laws and
regulations. For example, 33 states currently have breach notification
laws with additional states and cities (such as New York City) considering
them. While most of the laws are modeled after California's SB1386,
they often have slight nuances that must be considered. Implementing
best practices provides the best chance that your organization's data
will be protected from loss, eliminating the need to ever invoke the
States' breach notification requirements.
What are best practices based on?
A number of sources help define security best practices. One is ISO
standard 27001, which is derived from BS7799 and ISO17799. ISO standards
are available at www.iso.org . Another source of input is CobiT available
at www.isaca.org . While ISO 27001 provides standards on implementing
information security throughout an organization, CobiT is a process
for evaluating and managing risk in the IT environment. Neither provides
any level of detail on the actual settings to be used. The data security
standards required by the Payment Card Industry (PCI) provides the
most level of detail and is the best example that I know of, of an
industry's definition of security best practices.
How do I translate best practices to something that is meaningful
to me?
Two resources can help you make the translation between best practice
recommendations and i5/OS configuration settings. One is the iSeries
Security Reference manual available from the IBM Information Center.
The other is the book I co-authored with Patrick Botz - Experts'
Guide to OS/400 and i5/OS Security. The recommendations in both
publications are based on security best practices.
What if I can't set my system to best practice recommendations?
Quite honestly, it's rare that a system can be implemented using
all of the recommended best practices settings. Security is often
about trade-offs - in some cases, you must trade-off the most secure
setting for allowing functions to work. For example, it is rare that
systems can be configured with QLMTDEVSSN turned on. That's because
most users require more than one session to do their jobs. In cases
such as this, I recommend that you write a risk acceptance statement
explaining why the system value must stay off. Other examples of risks
that you may accept are leaving the QLMTSECOFR system value off, not
enabling the automatic time-out system values (QMAXSIGN, QMAXSGNACN,
etc) but using a Microsoft Active Directory policy instead, etc.
Carol's Tech Tip
SkyView Risk Assessor for OS/400 and i5/OS provides a complete risk
assessment that measures over 100 risk points against security best
practices. There's no need for you to guess or wonder what i5/OS settings
constitute best practices. Risk Assessor provides you with that information.
In addition, Risk Assessor is updated each release of i5/OS with the
latest configuration settings that require examination and evaluation.
Risk Assessor is self-contained. That is, unless you choose to have
SkyView Partners perform a periodic assessment for you, the information
never has to leave your system.
Risk Assessor provides the evaluation. The main Risk Assessor report
provides you with complete explanations of why a particular configuration
is being examined along with the risk associated with it. "Raw
data" is interpreted and an explanation provided in the Risk
Assessor documentation. When you review a detailed report, you know
what you are looking at and how to interpret the results. In addition,
Risk Assessor provides you with the information you need to determine
if the risk is sufficient such that you need to fix the issue immediately,
accept the risk or put a work plan together to address the issue in
the future.
Risk Assessor is repeatable. You can run Risk Assessor on a periodic
basis to ensure you understand how the configuration compares with
best practices. Also, as you remediate issues, Risk Assessor's documentation
provides auditors with a documented progress report.
Risk Assessor meets the requirements of ISO27001, HIPAA and PCI that
require periodic security assessments of your systems.
