SUMMARY OF RECOMMENDATIONS

hamburgerfensuckedSecurity

Nov 20, 2013 (3 years and 8 months ago)

79 views


SUMMARY OF RECOMMENDATIONS


Selection of ISMS
approaches,
features, methods and principles:



Merge of
M
ultiple
A
pproaches
R
equired

-

I
dentify
S
cope and
Parts

of an
E
ffective ISMS:

o

T
here are a number of complem
entary approaches

to managing informati
on
security.
Each approach

tackle
s

different aspects of the

information security
challenge. NCOIC
members
find that a single approach
does not sufficiently cover

information security.
We

recommend developing an overarching s
ecurity management system that
orc
hestr
ates the various
approaches. Just as no one security framework is suitable for all
situations and applications, so no single framework should be relied upon as the sole
guide for any enterprise. Multiple perspectives are necessary to provide for real
istic
secur
ity, and multiple documents provide

additional viewpoints to add to the
construction of a security architecture.

o

SMS uses “qua
lity management” principles, with management

based on an objective
assessment of safety risk rather than on customer satisfaction.
NCOIC does

not think a
management system like the SMS that is relatively closely aligned with quality
management systems is sufficient on its own to achieve appropriate
information
security.
The SMS states that it is “risk based” and “process oriented
.”
While these are
good principles that the ISMS should also i
nclude, there are additional principles
outlined
in this whitepaper.

NCOIC recommends that FAA
choose a combin
ation of
those principles to get the required ISMS feature set. Continuous improvement should
not be the only end goal of the ISMS, in addition secure architecture/

design/

construction/deployment need to be mandated to be more preventive than proactive.


o

SMS pres
ents three cornerstones:
corporate
approach, organizational tools and safety
oversight
.

This section is too generic to be

sufficient for
information security. T
he
entire people process lifecycle, information lifecycl
e, and IT system lifecycle sh
ould be
covered as well. NCOIC recommends a
ssess
ing
other risk management approaches in
the organization, not just SMS, to establish a common baseline of principles and
approaches. Similarly, align the chosen ISMS methodology with existing security contr
ol
frameworks, and with planned security control frameworks for NextGen.

For example,
for system level or “system of systems” level information security, NISTs guidance may
be particularly well aligned. For enterprise level information security, Risk IT m
ay be
particularly well aligned
.
OCTAVE may fall between the two
.



Security By Construction
:


A sec
urity management system should

include the notion of
“building security in” across the entire process/manag
ement and technology lifecycle. T
his
is not enoug
h,
however;
the ISMS also needs “secure by design/construction
.


An
appropriate level of i
nformation security for a
technical system of the scale and distributed
interconnectedness of air traffic management needs “security by design
,” in which
processes
a
nd technical systems are

designed and

built to support

appropriate security. The
general approach of commercial enterprises to build whatever functional features are
needed, and then try to retrofit security using information security “band aids” usually
r
esults in inadequate security.



Certification/Accreditation:


I
nformation assurance (security) accreditation/authorization
schemes such as Common Criteria are clear
in stating that the

full lifecycle “building security
in” approach is needed.



Full
L
ifecycle

Approach
:


Security should

be built in across the full
technical and
organizational
lifecycle (architecture, design, development, testing, deployment, operation,
update, retirement
,

etc.) The ISMS does not cover this a
spect, but
should do so
. Incremental
improvement based on hazards and failures is necessary but not sufficient.
Furthermore,
the SMS states that t
he “protection functions” (
safety management) of operators are not
entirely separated from t
he “production functions” (
the actual business). This w
ill also apply
to the ISMS. In particular, IT systems/applications and information processing for
“production functions” must be designed upfront and throughout the entire lifecycle with
security requirements (“protection functions”) in mind. Retrofitting
security will not work
for a complex, m
ission
-
critical environment such as

SWIM. SMS outlines the two main parts
of the SMS: Security Risk Management (SRM, see flow diagram, SMS page 29) for the initial
identification of organizational risk controls, and S
ecurity Assurance (SA, see flow diagram,
SMS page 40) to ensure effectiveness (performance). It is important that, while the ISMS will
also include SRM and SA, the ISMS needs to go beyond that.

NIST 800
-
37 states that the
listed tasks can be executed concu
rrently or as part of system development life cycle.



Preventative:

SMS states

that safety management should

be proactive rather than reactive.
The same critically applies to information security management (and also to the controls
implemented). H
azards
and failures need to be prevented by design as much as possible.



Systems + Oversight Approach:

The SMS states it is based

on a “systems approach”
(
“management
-
based”) vs. a pure “oversight approach”, with certain "safety attributes
."
The ISMS should also b
e based on a systems approach, and clearly state the matching
“security attributes”
pon which it is based.
For the ISMS, both
are

required, and oversight
may

be required to ensure the systems approach is followed through correctly.

On a
technical level
, a
“system of systems” approach to security is required to adequately protect
the complex, interconnected IT landscapes used to process information (Common Criteria
accreditation for s
uch systems is particularly difficult
).



Consider trade
-
off between flexibil
ity, speed of execution, and s
tandardization:

SMS states
that there needs to be a balance between flexibility of implementation and functional
standardization of useful safety processes. T
his applies directly to ISMS as well
.



Clarify Security Concepts
:
Th
e general notions of “insider vs. o
utsider” attacks (and

deperimeterization

) and

“accidental vs. malicious” attacks should be clearly explained in
an security management system, as they significantly impact the attack surface and the
controls necessary
.



Root Cause Analysis:

SMS mentions that the evaluation of the causes of a saf
ety issue is
important.

This “root cause analysis” is often forgotten in ISMSs but should be added into
FAA’s ISMS. It should also be linked with

the matching SMS activity as

secu
rity failures can
cause safety failures.


SMS explains the difference between a traditional and a modern view
of incident causation.

The same can and should generally

be applied to security.



Defense in Depth
:
SMS introduces “defenses
-
in
-
depth
,”
a classic se
curity concept whi
ch
should be covered
in a security management system. It needs to be made clear that
pra
ctically all controls can fail.



Gap Analysis:

SMS suggests a safety gap analysis to get organizations with existing safety
programs transitioned

to SM
S. This should also be included in the ISMS
.



Reporting System:

SMS
outlines a reporting system which

can be re
-
used for a security
management system
. NCOIC members concur.



Business Focus:


Security must be clearly aligned with business needs and

return on

investment, in order for

concr
ete implementations to be approved by leadership within the
FAA
.

In particular, clarify the priorit
ization of security goals. W
ork with non
-
US air traffic
organizations has shown that integrity seems to be the highest priori
ty, with availability
second, and confidentiality third. However, the prioritization should include additional
aspects such as accountability, business continuity etc.



Cover

M
alicious
C
auses
:


A key difference between safety and security risk analysis is t
he
consideration of malicious activity
. The SMS

does not consider dangers an
d harms from
malicious activity.
It
is recommended that the ISMS be structured to identify
risks from
malicious activities
,

including likelihood and consequences of malicious activity.
The ISMS
must be defined so as to assess and evaluate the likelihood of malicious cyber security
related activity, other potential consequences of this malicious activity that may not be
covered

by the SRM, design security assurance functions that lower the likelihood, and
promote the security assurance functions.



Stress the
linkage between safety and security
:

It is recommended that existing SMS and
defined ISMS frameworks are meshed together. The integrated SMS
-
ISMS framework must
support:

o

SMS accounting for safety hazards, dangers, harms of malicious activity

o

ISMS accounting for unique aspects of malicious ac
tivity which may not have direct
safety impacts

o

ISMS accounting for NAS ATC system survivability under information security attacks

o

Producing a coordinated response from the SMS and ISMS to any change in the NAS,
incident within the NAS, or incident due t
o the NAS.



Include a G
overnance
M
odel
A
ligned with SMS:

The ISMS governance model and process
should adopt and function similar
ly

to the SMS governance mod
el. Accommodations must

be made to facilitate the near instantaneous availability of information and

the need for an
expeditious decision making authority. Adopt an integrated method (potentially aligned
with TOGAF, which
portions of the
NAS EA is based on) that includes internal and external
security experts, and draw from experience from other governme
nt agencies.



Navigate the
Policies and Politics
:

Clearly communicate societal

aspects inside FAA to
minimize resistance to change an
d

facilitate acceptance of the ISMS



Comply with G
overnance
D
efinition and
G
overnment
D
irectives:


It is r
ecommended
that
IS
MS technic
al specifications and policies, as seen in Task 3,
be in compliance with the
governance definitio
n. In addition, respective US g
overnment agencies directives should be
incorporated into the definition of the ISMS policies and objectives. The sec
urity policies and
objectives are outlined in C
omponent 1.0 of the ISMS.



Alignment of ISMS with SMS



Recommended C
hanges to the SMS
A
nalysis and
P
rocess

include
:

o

Incorporating statements regarding the awareness of Information Security and
references to
the ISMS document and processes. Element 1.1 would be revised to
include security as part of the safety policy. Element 1.2 would define the responsibility
of information security as it relates to safety issues. Element 1.3 would identify ISMS
key perso
nnel. Element 1.4 would define the preparedness requirement and integrated

response requirement with ISMS

o

Based on a well
-
defined security magnitude of impact to safety hazard mapping using
actua
l data and FAA guidelines, an SRM safety analysis should be p
erformed and
the
impact is identified as
,

and feeds into
,

the SRM as a h
azard

o

FAA Order 1100.161, Air Traffic Safet
y Oversight, should be updated to add “Security
Posture Change”

as a category of c
hange requiring safety analysis

o

The FAA SRM process defined

in the FAA SMS Manual
should
be updated to reflect
approved changes to the FAA Orde
r and that “Security Posture Change”

be added as a
category of change (see figure 6).


Alignment with

security technology and technical architecture
depth/
scope



Technical F
ocus Needed:


o

If FAA wishes to produce a
high
-
level generic security management framework
document, it should clarify in depth that there are numerous complexities on the other
layers that dramatically impact the overall effectiveness, and establish proces
ses to
mitigat
e those issues
.

o

The NIST 800
-
37 guidelines have been broadly developed from a technical perspe
ctive.
NCOIC
recognizes that

this may not be the preferred
approach for FAA at this stage,
h
owever, we believe that an
ISMS must

be more technica
l i
n nature than an SMS, as

information is mostly processed by ICT systems.

o

SMS states that “safety recommendations should state what should be done, not how
to do it
.”

While this is a good approach to set the high
-
level direction, the ISMS will
have to prov
ide some “ho
w” implementation guidance, and
will also need to inform
the
“what” as to available technical solutions. It is difficult to provide a
useful ISMS without
having the “how” it can be done in mind at all times when writing “what” should be
done.

For example,

while mitigating control selection (on paper) is a nec
essary step,
the problem is which

controls can actually be implemented and are available/viable etc.
(esp. for IT systems).

o

The SMS states that it has “organizational process controls” on
ly. Due to the fact that
information is mostly processed by technical inform
ation systems, the ISMS should

focus on technical controls too.

o

Information security is by definition more IT centric than safety, because most
information for the NAS is processed

by IT systems. The relevant security is mainly a
software concern (because this is where the complexity is), but hardware security
concerns also need to be taken into account. What this means is that a more technical
approach than the SMS is required for
security.



Work Flow Process Approach to System Assessment:


The SMS states that it is based on a
“work flow process approach to system assessment
.”

This can be reused for the ISMS,
although stronger focus is required for (technical) system design and (tec
hnical) security
acro
ss the entire system lifecycle,
inclu
ding design and implementation.



System vs. People Failures
:
The difference in security between IT system s
ecurity failures
and people
security failure

needs to be addressed, and


due to the high au
tomation IT
systems offer regarding information


resides heavily with IT systems security
.



Go B
eyond
T
echnical
C
ontinuous
M
onitoring:


SMS states the need of

continuous
monitoring of the effectiveness of the SMS. This is absolutely necessary, but should n
ot be
confused with the same term used in the information security community for technically
monitoring systems security on a continuous basis. This technical continuous security
monitoring is necessary but not sufficient, because it is reactive, no
t proac
tive


the ISMS
should
ensure that proactive/preventative controls and architecture/design/lifecycle
processes are also put in place.



Security M
anagement and
S
ecurity
T
echnical
A
rchitecture
M
ust be
C
onsidered
T
ogether
:

If
the dots are n
ot connected acros
s all layers
, there is a great risk that each layer (esp.
management, and technology) are coher
ent at their layer, but have

no clear connect
ion
between the layers. I
mportant aspects
of
layers are often omitted at other layers (e.g.
certain new security te
chnologies make new controls selection possible, or make controls
obsolete, or change risks). All layers are influ
enced by all other layers, so NCOIC

recommend
s

an iterative, spiral ISMS/technical architecture process similar to agile
development. In parti
cular, the connection between controls
-
based ISMSs and technology
innovation should be con
tinually examined.
Mitre discusses how information flow control
across NextGen will be a critical requirement. Technic
al security policy management, in the
sense of
fine
-
grained access policy rules) is only viable if the NextGen SOA is built in a
certa
in way, and if innovative, model
-
driven security

approaches
are used to generate the
rules. Without this,
SOA agility, assurance accreditation/certification, and least
privilege
can
not easily be achieved
. What this example shows is that such technical innovations can
inform the selection and scope of c
ontrols in the ISMS.
FAA’s ISMS should not be “paper
exercise
.”



Align

with DOD, NSA, NATO

I
nformation
S
ecurity
S
tandards
:

o

The ISMS will manage multi
-
level security data flow at the hardware interface and
physically/logically provide separation between the various high secure system
s

to low
secure systems.

o

The degradation of data from high level to low level will require a c
ustomer security
approval and will need to be coordinated by the security focal

points
.

o

The elevation of data from low level to high level will require security involvement to
ensure data isn’t include any malware information.






Recommendation for I
mpleme
ntation of the ISMS:


o

T
he ISMS is a phased approach to
identif
ying the critical assets requiring

protection at
the high
-
level. Once t
hese assets are determined, the
physical and logical separation will
be enabled at the hardware level through policy based

rules.


o

Once the access levels are determined
,
data flow sources must be a filter on the firewall
system

by origin and destination
.


o


The data in

movement must be in compliance with the data encryption (xx level)
imposed on the network segment.


o

The secu
r
ity policy should
be a nested policy based on the placement of the assets
controlling the safety network.


Alignment with NAS EA



An
Overarching R
isk
M
anagement
S
ystem
may help align specific risk management systems:
One way of aligning the various risk
management aspects FAA is concerned with would be
to design an overarching risk management system, which should be aligned with overall
business management and EA. So f
ar, FAA seems to have some
basic provisions for this in
NAS EA, while other FAA publicat
ions such as the Safety Management System and the Risk
Management Handbook are concerned with isolated aspects of overall “business
” risk. If all
specific risk management systems (safety, security etc.)
were based on an

overarching risk
man
agement system
, all systems would be
comparable and aligned.



Use DODAF/TOGAF

A
rchitecture
F
ramework:


Identify and adopt an industry standard
Framework and Methodology that accommodates the commercial aviation industry. The
use of the current NAS EA is conducive to tho
se agencies that use DODAF as an architecture
framework. This framework and methodology should be readily available to participants
and based on the open framework concept.


The security enterprise architecture coul
d be
modeled in line with DoDAF or
TOGAF
, as DoD and other agencies across the globe are
doing. This way, a unified architectural view can be ensured. It is important to use good
modeling practices with formalized meta
-
models to ensure semantics are correctly
captured.

o

The NAS EA should

incorpo
rate the airplane/aircraft as a node entity in the definition of
operational nodes and corresponding connectivity (OV
-
2).

o

The NAS EA OV
-
3 should be revised to define and incorporate Security Management as
both a sending and receiving function. (Please see

page 8 of the NextGen 2025 OV
-
3 as
an example of Safety Management. (https://nasea.faa.gov/file/get/930)

o

The Systems Interface Description (SV
-
1) should be reviewed to incorporate Information
Security system interfaces.

o

For future consideration, a revisi
on to the NAS EA to include a major deliverable that
addresses informa
tion security. Perhaps an Information Security
-
1

document that
defines the information security functions and standards.



Cover System Malfunction

and Malicious Causes
:

The SMS is a mea
ns of controlling safety
hazards that originate within the NAS, or in which

a NAS element is a contributing

factor.
The scope of the SMS does not cover causes of system malfunctions
,

nor how system
malfunctions create safety hazards. For example, SMS can b
e used to define ATC procedures
that manage an in
-
flight emergency and assure that the emergency does not contribute to
the possibility of an accident
. The SMS cannot be used for what caused, and how it caused,
the in
-
flight emergency.

It is recommended t
hat
the ISMS address
vulnerabilities and
attack
s that exploit vulnerabilities, as well as
how these maliciously induced malfunctions
r
esulted in flight
emergency
.



Include Survivability Considerations
:

Successful attacks on information and information
tec
hnology in ATC systems may cause unplanned and unanticipated disruptions, potentially
degrading NAS performance. Furthermore, a t
hreat may be dormant for a
time before it is
active
, and may continuously evolve. T
o
maintain safety and minimum performance l
evels
of the NAS, system survivability considerations are recommended. The ISMS must include
both information security and system survivability considerations in the NAS.



Leverage RTCA
-
216:


It is recommended the NAS leverage RTCA SC
-
216 findings and resu
lts
as guidance for developing the ISMS.

RTCA SC
-
216 committee for Aeronautical Systems
Security is developing airworthiness security standards that bridge with airworthiness safety
standards for the purpose of commercial aircraft certification.



Balance
Avionics and Ground Systems Security
:


It is recommended that information security
considerations for air
-
to
-
air, air
-
ground, and air
-
to
-
satellite commu
nications interfaces in
the NAS

carefully balance the need for avionics security versus ground systems security.



Due
D
iligence and F
iduciary
R
esponsibilities:

The NAS has multiple business domains. It is
recommended that the ISMS must provide confidence that the information security is

properly managed as required by FAA regulations and the executive management of the
stakeholder business organizations. Each stakeholder business organization must be
expected to perform their diligence and fiduciary responsibilities with respect to both
information security and their business in the NAS.



End
-
To
-
End Security:


I
t is recommended that
the
end
-
to
-
end security principle is used for
securing information flows through distributed ATC systems in the NAS.



Recommendation for
I
ntegrating ISMS into
the NAS EA
:

o

Where data needs are highly secure,

the framework
should be
integrate
d

with NAS EA
a
t the point of inflection
.

o

W
here data needs are less secure
, the FAA
should be able to have this policy run on a
low band
-
width.



Extend NAS EA Security Requirem
ents:


The NAS EA Requirements Document states a few
very hi
gh
-
level security requirements which do not seem to be sufficient. A

detailed analysis
of the actual requirements across all layers should be carried out a
s a continuing task.
R
equirements will
likely change over time as the environment (technical, business, end
-
customer) changes.




“Model
-
D
riven
S
ecurity”
approaches should be considered:

o

A
s a process to turn a potential high
-
level FAA NAS EA security model into concrete
implementation for the tec
hnical asp
ects of information security, and

o

To reduce the time and effort needed to create accreditation/authorization (e.g.
automatically generate Common Criteria supporting evidence)
.

As previously
mentioned
, information security is to a larger extent
a t
echnology concern than safety
,
because most information is automatically processed by information systems.



Security

M
ust
S
upport SWIM’s
A
gile SOA:


SWIM is

a core part of the information
-
related
architecture of NAS EA. Since SWIM is based o
n agile SOA
, security approaches,
controls,
and mechanisms should

fit to this complex, ever
-
changing IT landscape. A good solution is to
design security into the overall SWIM architecture across the entire development/

deployment/t
esting/operation/retirement

lifecycl
e.


M
odel
-
driven security approaches can
help implement policy and achieve accreditation for those agile IT landscapes.



Enable
/Empower

IT
Teams

to design state
-
of
-
the
-
art architectures
, including
secure
-
by
-
default, secure
-
by
-
construction, model
-
driven from

NAS EA to agil
e technical
implementation etc.
, including identity/authen
tication, authorization/access and
logging/monitoring.

Also, cloud security will play a role for FAA’s SWIM and other IT
adoption, because cloud application “mash
-
ups” have many of t
he same characteristics and
security concerns as

SOA

applications . Particular concerns with cloud computing security
are the lack of both control and visibility over the security of cloud services (f
rom the
consumer’s perspective): see FedRAMP. C
over st
ate
-
of
-
the
-
art system architecture
knowledge methods, and supply chain/outsourcing security risks.


Certification and authorization o
f

systems



Accreditation Scheme Needed:


Authorization of IT systems security is a costly and complex
topic, as shown by the

Common Criteria process used by DoD and others.

Without such
accreditati
on

schemes, it

is difficult to quantify
the effectiveness of a security management
system.

It is also important to note that traditional Common Criteria currently fails for
dynamica
lly changing, interconnec
ted IT landscapes such as SOAs
.

Model
-
driven security
approaches have been shown by DoD to help shorten accreditation times for agile SOAs
,
such as SWIM
.



Certification:


SMS mentions safety certification. This is also important fo
r ISMS, and should
involve both security process maturity and secure design/development/deployment
.


I
nnovation

Scouting



Look for
I
nnovative
S
olution
s
:

Innovative solutions
will be needed throughout the life of
NextGen.
NextGen will change many of the traditional information security management
and design assumptions of NAS. In particular, SWIM will be based on agile SOA, for which
information security is difficult to implement and manage.

In general, sec
urity and agilit
y
are difficult

to align. At the same time, security must not impede the business case for SWIM

and agile SOA. Security
must fit into those changing environments without negative impact.
In order to achieve this, security must be designed into NextGen thr
oughout the entire
lifecycle, so that management and technology choices are made that enable appropriate
security. Retrofitting security for NextGen will likely fail. Security needs to be built in “by
construction
.”

This mea
ns that FAA should begin solving

innovative security management
and technology issues
for SOA security as soon as possible, so that NextGen can be designed
with those so
lutions in mind
.


Other/miscellaneous



Section 5
(pages 55 and onwards in the ICAO document)
of the SMS most likely cann
ot be
reused for the ISMS, but other information security related standards and guidance
documents can be included in such a section in the ISMS, e.g. NIST’s guidance.



Intended audience:

Make clear who the intended audience for the ISMS document will be,

so that the document can be targeted at that audience. Is it for FAA, for operators, for IT
suppliers? Is it for security professionals, IT professionals, or aviation industry professionals?


Rec
ommendations: Further a
nalysis

needed



Further investigation
into the commonalities or overlap between the two processes in
controlling and mitigating security risk and mitigating or eliminating safety risk and the
potential efficiencies gained or coordinated activities that may be leveraged using the
defined and ap
proved FAA Information Systems Se
curity Program is performed



Further investigation into a more relevant and detailed mapping between security
magnitude of impact and security hazards based on actual data and FAA guidelines is
performed.



Further
investigation into the use of security requirements modeling, and the use of model
-
driven security to turn these models into concrete technical NextGen SWIM SOA security
implementation. This includes further investigation into the planned overall technical

architecture and software/systems development processes for NextGen. This also includes
further investigation into the use of model
-
driven security approaches to reduce the time
and effort to achieve system certification/accreditation/authorization.