Information Technology Reference
In-Depth Information
3.4 Database of Technical Controls
This component is the counterpart of the SO, and describes the technical actions
(“How”) in order to fulfill the security requirements identified in the SO (“What”),
being actually a collection of security controls in a technical level; examples include
executable programs and scripts, tools, secure configuration settings and security
patches. These controls address, among others, the specific threats and vulnerabilities
of IS and are
highly technology- and platform-dependent
. For instance, a script con-
figuring a certain access device in order to enforce a given access control policy, may
be inappropriate for different versions of the device software.
The idea is to provide customized, focused solutions in the technical level that
address given security requirements of IS. These controls are organized in a relational
database for easy retrieval and query support. Metadata of these security controls in-
clude, among others, the following attributes: target platform, operating system name
and version, target domain, authorization level required, action performed, time con-
straints, prerequisite conditions for successful execution, clean-up actions, etc. The
database of technical controls is by no means complete and/or static ; it should be up-
dated in regular periods with the latest technical controls. The database schema defini-
tion, as well as the database management itself, is out of scope of this paper.
4 Security Management Framework
In this section we present a brief description of the necessary steps in order to esta-
blish the IS security management framework under examination. Four major phases
can be identified throughout the process, namely: a)
Building of Security Ontology,
b)
Security Requirements Collection,
c)
Security Actions Definition, and
d)
Security
Actions Deployment and Monitoring
. The steps in each phase are as follows:
1.
Building of Security Ontology
I.
Get IS infrastructure data
; in this initial step, vital data concerning the network
topology, technologies used, servers, wireless access points, services and a-
ctive ports are located through the use of network scanning tools such as Nmap
[24] and NetStumbler [25];
II.
Justify with organization managers and discuss business decisions
; manage-
ment input entered into the knowledge system via dialog-based interfaces may
influence dramatically the security of the IS, since it might affect network to-
pologies, active services and open ports.
III.
Generate ontology concepts' instances from infrastructure data
; in this step
there is enough information in order to generate instances from the correct
concepts of the SO. Populate the instances with information from step I. The
management of concepts' instances and population may be performed via on-
tology environments and tools, such as Protégé [26].
2.
Security Requirements Collection
IV.
Extract security knowledge from the IS policy document
; perform information
extraction work from the policy statements and populate the ontology concept
instances with the extracted information, using tools such as GATE [16].
Eventually fill the gaps (if possible) in the instances from step II.
