Click here to get the file - AFCEA DC

sweetleafnotebookΚινητά – Ασύρματες Τεχνολογίες

12 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

65 εμφανίσεις

General:

In addition to mapping to NIST SP 800
-
53 Rev4, call out more clearly the tie to the RMF (800
-
37)

Vendors indicated that even with a minimal security baseline, they still face hurdles Agency by Agency
proving their products comply with the
baseline. Once Agency may feel the product complies, while
another Agency does not. This increases the cost for the vendor. Maybe consider a FedRAMP lite for
the mobile products/apps. Related suggestion leverage DISO FSO reviews.

As discussed in the me
eting, legal issues are still “front
-
and
-
center” in everyone’s mind.


Our table
believes that the gov’t can get past these IF concentrated and creative thought is applied.


Legal issues
should not be “strung out” over the next year or so


they can be hand
led quickly if a concentrated
effort is applied

Policy guidance is still too general.


A tiger team focused on providing more policy details is
recommended.

Requirements might be getting conflicting or guidance from Federal Gov. is conflicting?

The overal
l goal for any cross
-
Department mobile team could/should be, “short term business benefits;
long term roadmap; reduced cost to conduct business!”

A responsibility for any cross
-
Department mobile team could/should be, “increase outreach and
education to age
ncies.”


There is still too much redundancy, reinvention and stove piping in
agencies.


Have someone coordinate information exchanges from proof of concepts; introduction of
new technologies, best practices, etc.


Today’s meeting was great… do it again, bu
t also hold a gov’t
wide telecom to continue the momentum; or use a crowd sourcing piece of software such as Idea Jam to
continue to expose issues and zero in on answers.

A small criticism for some of the speakers


too many of the issues presented were th
e same ones
discussed a year ago.


The Govt needs to id someone that will take certain issues to the finish line.


Focus
and apply creativity on the priority issues
-
set the expectation that priority issues get resolved and put
behind us.

A complement


you
r decision framework and overlays are an excellent idea.


Keep driving towards
more details… in some cases, it might even be advisable to become “prescriptive” in nature but you
have identified an excellent starting point.

Do we further define separation o
r definition around MAM vs. MDM or let it shake out?

Don't reinvent the wheel

Don't apply desktop oriented security frameworks to a mobile centric scenario

The

overlay may be a little heavy and a more
simplistic or

consolidated approach may need to be
adop
ted, too cumbersome.

Government folks are viewing the overlay as the bare minimum

Requirements

need to be less aspirational and more real
-
world

Need more high
-
level requirements

Security at every layer

Secure

API level integration

Piece between device and
app OS/middle layer is w
here the security is lacking, d
own to the chip level.

Companies partnering with MDM companies to develop these
-

no reinventing the wheel.

Benefit

to the govt, not locked into a single vendor solution

Mission focused, shouldn't recr
eate the wheel and make
new solutions

when not needed

Approach

is understandable but everyone's goal stake is different

M
obilespace is moving quickly to meet what
the

federal government is asking for, the focus of your
organization

Don't need to over compl
icate
-

procurement requirements, should be more simplistic consolidated
approach

Overlay

is built towards what's been traditionally alone on the PC side not the mobile requirements

Mobile Device Management/Identity Management



Government “broke” and has
little to spend on R&D, looking to industry



Government seems to be creating definitions for MDM, products and service offerings
fragmented, many point solutions aren’t integrated



Many requirements are based on desktop computers and are not applicable to mo
bile devices,
but mobility is also not just a phone.



Networks and OS architecture, container of applications all different



Diverse mobile ecosystem, vendors want to keep you locked into their platform



There was a recent Gartner report that indicated that n
ot everyone needs the “Cadillac” or
upper right hand quadrant of MDM capabilities.


Booz Allen has a decision model to use with the
Gartner Tiering


the result should be that agencies can have easy
-
to
-
use tools to help them
determine whether they need sim
ple, moderate or complex device mgmt. tools.



Agencies should implement policies on inventory management, device access to agency
networks and the acceptable roles between split personas on a mobile device.



Consider classifying/defining smart devices in the

context of an Agency’s assets: are they
endpoints like desktops and laptops or are they something more?



Establish a reasonable and usable set of profiles



Two different policies/solutions are probably needed for BYOD vs. GFE



Legal policies needed with BYOD

and the need to wipe or reclaim personal devices as well as
potential acceptable use and the deployment of an enterprise container (e.g., OS)



MDM's should have the ability to wipe devices, continuously monitor, perform backup/recovery
functions and provid
e alerts.



E.g., use MDM to measure network usage to negotiate lower carrier costs and also use free Wi
-
Fi (when available) to avoid using pay per byte cellular data



MDM policy to enforce the use of
Wi
-
Fi

with
VoIP

due to bandwidth requirements



Pen test

to
validate desired policies and configurations



Verify what is being loaded on device is the known good state of what is intended to be loaded



Reduce licensing costs with the use of enterprise tools such as SCCM to manage Win8
Pro/Enterprise based tablets



Imp
ortant to secure the device through the MDM, but assume it will be compromised. Ensure
we have the proper controls identified to alert when it happens (AU family) and respond
accordingly (IR Family). Our table didn’t do a control by control review.

MDM



s
peed up acquisition cycles for industry to compete



life cycle management



standards that are adaptable will remaining
auditable



Can

we influence non govt standards to reflect govt standards?



agile controls



multiple changes with software/hardware based on
version/carrier



vetting app designs



open application alliance






Some general discussion on recent RFTC



Some discussion on why SP 800
-
53 Moderate Impact control baseline used; too restrictive,
should have more granular levels of “classification”



A team could
/should go through this NIST and map against mobile
environment

to identify gaps
and dated information that may not cover mobile security



too much, too many requirements



too DOD/Intel driven/centric which may be too
restrictive

for other departments and
ag
encies



no cross polinization for access and user need



specify
granularity

within user controls



some standards are irrelevant



May need to
implement

new requirements for mobility where there are gaps



Need to integrate MDM with MAM with TEM

with IDM with Ass
et Management with NIST
controls (e.g., 800
-
53 to create efficiencies



Have we covered everything recommended in NIST SP 800
-
164 (“….Hardware
-
rooted
Security…”)



FIPS 140
-
2 validated MDMs are not necessarily 140
-
2 compliant. Because they are relying on
the
certificate on the phone, they realistically can’t claim full 140
-
2 compliance.





Start at the lower
-
level of protection


OS/Data Layer



MDM is seen as the Top layer of protection



SE Android


Securing the Kernel with a secure OS



Platform Security



OS
Security



Does the Responsibility reside with the MDM to ensure and provision a secure
OS?



DoD previously hung up on device and is now putting more focus on the data; very comfortable
with Blackberry, less so with iOS and Android

MDM Key Themes:

Concerns
over MDM transport security
-

how can that be secured

MDM requirements influenced by legacy OS security capabilities

Hosted MDM (cloud based US customer premises)

Inter
-
govt verticals (Health, law enforcement, IC)

Consumer

focuses devices create legal con
cern

CDM
-

continuous monitoring of MDM
-

Big topic
-

how will devised be defined



-

NAC as a means to detect mobiles



-

MAM RFx too focused does not consider overall approach



-

MDM is focused on niche solutions

Monitoring and
enforcement

of security p
olicy

App

vetting necessary but not
sufficient
-

have to monitor app behavior and context of usage

Too

much focus on device
-

old paradigm of control, the endpoint

Industry is working with D/As for various implementations needed

Industry is focusing on
hardening core requirements

MDM and configuration
management

may converge in the future

"Cool" technology driving
requirement

vs. Mission driving them

Financial decisions made to save money vs. satisfying requirements


MDM Recommendations:

Push industry to

adopt FIPS secure

Agencies do risk analysis on hosted/cloud vs. agency managed

D/A's need to use the MCDF to develop patterns to help determine solution sets

Enhanced industry involvement is needed, especially during requirements gathering

Need more indus
try involvement in the requirements gathering phase

Agencies are providing conflicting requirements

Some

agencies are still creating business cases and developing policy

It

is difficult to keep up with the changing federal requirements

Difficult to keep up

with changing federal
requirements
, especially
when

designing a solution

We need cross
-
platform solutions that are secure and interoperable

What can be learned from commercial and foreign markets?

Need a framework that will support any platform allowing organizations to use devices
based

on
security needs

Tell

vendors what they need to provide, not how to provide it

Need to better address physical security (supply chain) of mobile devices in policy

Follow up

Follow

up with MDM vendors/OS vendors on 800
-
53 baseline

Focus on apps and data
-

that's where the value is

Specifications for use of supervisory software needs to be clarified

Interoperability testing next step around mobile deployments

Output
thus far is fairly complicated and many parties may benefit from high
-
level requirements or a
summary of existing work

Don’t

apply a desktop centric security framework to a mobile solution

Can there be a list (like UCDMO portfolio) that shows who is doing
what in these spaces

Make sure docs reflect actual requirements (business requirements to meet mission needs)

A

lot of focus is on secure apps
-

not so much on OS

Mobile Data management
and

Security

DAR
-

DAT provisioning (Data at Rest and Data in Transit
)

People at our table were not able to view or review the overlay sufficiently
beforehand
.

ICAM/IDM



Good policy, guidance and infrastructure (PIV
-
1, PIV, CAC)



Problem with how it is being implemented differently by branch/agency (e.g., DOD approach
defined

but not being implemented consistently)



Education required on standards



Improve the use of credentials (e.g., PKI, PKE) stored in hardware root of trust (e.g., TPM)



3 approaches to IDM



Device Attestation


the device can be used as 1 of the authentication

mechanisms when it is
attested



Agencies should have policies on the use and provisioning of derived certificates, as well as
acceptable forms of "factor" authentication.



Biometric authentication (facial recognition, finger print) seen as future possibilit
ies, looking for
more innovation around two factor authentication, needs to be integrated into device, after market
add
-
ons seen as expensive and sub
-
optimal



Derived Credentials



Are they acceptable as an alternative to CAC/PIV



Biometrics could be seen as a
n alternative for 2
-
factor authentication



The phone can be seen as the CAC/PIV by storing credentials in a “secure zone”



Agencies/govt partners should look at a standardized set of open source kernel APIs across
operating systems for bios level control of
devices.



Managing device policy such as geofencing capabilities to modify data/services delivered to devices
depending on the situation such as being within a secure area (SCIF)



PKI and certificate management with drive credentials is a best practice



Integrated IDM for people, apps, and devices



Need for process to certify/test against common standards



Can there be a governing body (e.g., NSA) for all agencies to leverage authentication; need common
process with reciprocity to reduce redundancy and imp
rove efficiencies in an era of doing more with less



Is it possible to consolidate independent multiple pilots inter/intra departmental



Improve the validation that the person with the device is who they say they are



Granular trust model to authenticate per
son (e.g., biometrics, CAC card, etc.), applications and device



Profiling based on security level



Different device security capabilities result in the need for different risk controls and enterprise
information services that can be delivered to that device



Capabilities will differ with BYOD vs. GFE devices due to hardware and software capabilities available
with consumer devices versus hardware and software standards that are defined by the enterprise and
acquired

Some repeat from above but topics can be vi
ewed as 6 issues:



Ref
architecture needs to address ID
M for devices, apps AND users



It also needs to cover related topics including authentication, authorization, digital
signatures, encryption, network admission,
etc.



Derived credentials really need to
become a reality



Continue to move to biometrics such as what DAON offers



Your overlay ideas are great… they need to go a little further,
though
.


For example, the
granular trust model mentioned above needs to, again, cover device, apps and user
identities;

also, the trust model needs to identify recommended mitigating controls,
perhaps by platform, necessary to raise trust.



Industry IT Best Practices



Maintaining Information Security while allowing Personal Hand
-
Held Devices in the Enterprises
-

http://www.intel.com/content/www/us/en/enterprise
-
security/intel
-
it
-
enterpri
se
-
security
-
maintaining
-
information
-
security
-
while
-
allowing
-
personal
-
handheld
-
devices
-
paper.html




Granular Trust Model
-

Improving Enterprise Security, IT best practices for dynamic controls and a better
user experience
-

http://www.intel.com/content/www/us/en/it
-
management/intel
-
it
-
best
-
practices/granular
-
trust
-
model
-
improves
-
enter
prise
-
security.html?wapkw=granular+trust+model



CAC
-
PIV



Token



BAI Controls
-

CAC external solution plug in



Why

can't part of the device be the card?



tokenization
-

insert into the device



soft token on the device, but can it be breakable



Biometrics,
iris
scans
?
Photo

of a photo? imperfect technology



device and
torshirey

to application



Risk

of taking ID off person, inserting it into a device and learning the device, like a phone, open
and vulnerable.


Theme: Data Protection/Storage is key

Theme:
Identity/RBAC should be primary driver

Recommendation: get feedback to and from users

Recommendation: affect procurement strategy

Recommendation: IAM: consider "continuous authentication"

Recommendation: Review "As a Service" model

Items for follow up: Com
munication strategy CIO
-

COTR
-

Procurement

IDM



soft certs bad



NFC loud



CAZ built in cost effective?



secure gesture 3



multiple devices



XX percentage that can't use PIV/CAC



secure payment industry



data dependent on authentication



risk based decisions



data

mining capabilities



financial services BYOD

IAM themes:

Support

for smartcard with phone form factor pathway to derived credential
-

what is the acceptable
level of risk

What data and systems is user accessing?
Email

vs. confidential DB

Cost of PIV/Smart
control vs. derived credential

IAM requires D/As to determine a clear path going forward (PIV
and

CAC acceptance or derived
credentials, etc.)

Should use organizational policies already approved instead of reinventing (data security, IDM)

Follow up:

What

are different industry verticals doing to solve mobile IAM?

What is the FIPS facial recognition standard?

IAM Recommendations:

Need for contribution of specific use cases

Need clear NIST guidance on Mobile IAM

MDM and IAM need to integrate

Derived credenti
al push

Application Management/Data Management



Data tagging remains a challenge but there are some solutions out there



RFTC seen as a wish list, no one solution out there, the challenge is how to integrate various
solutions



Application security seen as
key issue; begins well before application management
-

secure
code review, secure deployment, secure management (who has access to what applications,
monitor usage, etc.), how to manage the data the application generates



General mentality that applications

gotten from App stores are “safe”, how to prevent
introduction of malware



Need established test facility common to government (similar to Common Criteria program
or FedRAMP’s 3PAO), currently spending too much money on test facilities



Users cannot assume
connectivity when using applications, what happens when
connectivity is not available



MAM doesn’t provide Security natively



Containerization



App Wrapping



App Vetting


Source code review



Human App Vetting



Data Security



DRM



Data Tagging in enterprise is key to deploying good DRM



How does the government staff a manual App review process



University Model?



Who pays for it, Government or Vendor?



MAM Features



Injecting Data Loss Protection


Copy/Paste restrictions



Policy Manage
ment on a Per App basis


Geo
-
fencing, added layer of authentication etc.



IDAM with the App Catalog


MAM

-


Each agency should have a policy advocating technology/procedures to validate the authenticity
of apps, especially in cases of access to the gov
t
/corporate side of a dual persona device.

-


GSA should establish a Fed App Store which is integrated with MDM providers.

Though we had lots of good discussion, that's all we could come to consensus on.

Need more
visibility

about DHS car wash and NIST 800
-
163 app vetting framework

Cross

platform solutions don't exist

Need

standards for MDM/MAM and interoperability

Need

commercial entities to work together to create usable solutions, applications don't talk to
each other
.

App
Mgmt.
:



Characterize user profile

(e.g., mission, user roles, data classification level) to help define security
requirements process during SDLC



Embed security capabilities/requirements within an enterprise app store and vetting process



Need a process to review applications that have bee
n submitted



Application risk assessment process



Need a common and efficient mobile application development process



Mobile application development and management should leverage industry best practices such as ITIL
release management and security patch mana
gement processes/tools



The model to develop and acquire application should be assessed with regards to pay per app use
model, impact to industry and government procurement process



E.g., NASA space application challenge and HHS (Todd Park) application devel
opment challenge



Development process of mission applications will probably vary from public facing (e.g., citizen
data/services) applications



Need for a federal clearinghouse for application security requirements definition testing and
validation/certifica
tion with documentation similar to how FedRAMP is doing this with the Cloud



Differences with data classification levels (e.g., unclassified, secret, TS)



Reciprocity of documented or XML output of
secured

test process (Apple Appstore is a reference point)



S
andboxing and securing access to secure networks without data exfiltration



Risk management framework giving access to all enterprise resources based upon real time situational
characteristics (e.g., geofencing capability based on location, networks, applic
ations in use, role,
peripherals (e.g., video, etc.) being used)



Data
Mgmt.

-


Agencies should have programs or policies addressing role based permissibility to data, integrity
services,
geo location

as a controlling method for data access, standards for DAR/file transfer and
data "provenance".

Data



Basics


secure data at rest, secure data in transit and secure the data in process



Leverage hardware root of trust such as TPM and Trusted Execution Tech
nology



Increased education of Data.gov data sets, measure their usage and incentive more use, need to unlock
the value of the data



Positive


DISA SRG for data development



Development frameworks that are interoperable, device/OS agnostic, leverage local de
vice resources
and redirect processing to the device when possible to provide the best possible end user experience,
reduce cellular network usage and potential more expensive data center compute resources



Need access to the same data with consistent
standards from multiple devices (e.g., phone, tablet, PC)



Army Common Operating Environment is an example



Use: Containers, transports, drop boxes, content management systems



Look at the use of virtualization of data/apps to enable use across multiple devic
es, the use of web apps
and native application and virtualized applications based on mission needs and situational capabilities
such as bandwidth



Virtualization is not a one size fits all, some mission needs require native applications without or with
limi
ted connectivity



Ability to check out a virtual container and run on device in a secure manner without connection

__________________________________________________________________

MAM/Data



To

the extent possible, bolster the focus on data security before
all the other areas. If govt can
secure the data and have
storm

access controls to it, the other areas are not quite as important.



For

MAM, ensure the controls are at the proper granularity to cover both native and Web
-
based
apps.



For

MAM, do we need to di
fferentiate controls specific to internal
and

external apps?



Align data controls against DLP
principles

(at rest, in use, in transit). DRM would fall under DLP


Focus on app
mgmt.

vs. device
security
.


MAM/DATA themes:

MAM
-

static code app vetting for
federal

MAM
-

application life cycle (define it)

Data tagging (content)

Data retention, policy, guidance


MAM/Data Recommendations:

MAM
-

static code requirements for each agency

MAM
-

mobile and application life cycle (similar to DOD strategy)

GSA RFTC
addition of tools/
requirements

MAM needs to be defined throughout the full lifecycle

Government would benefit from streamlining discovery of critical
requirements
.

Define data lanes

Data

retention, guidance, enterprise protection

MAM
-

need to look at the
full lifecycle from development, test, vetting, management, performance,
etc. Not just MAS

DATA
-

rights management
-

may need to stand up a group to look at categorizing and tagging data and
federation for authoritative source across govt.

Follow up:

MAM

include in baseline

MAM ISIMC MTTT Discussion

Data
-

NIST