>> All right.
Hello everyone.
We are here today
to do a webinar
on the trusted internet
connection
and IT modernization efforts
being undertaken as related
to the trusted internet
connection
or TIC update initiative
that's been coming out of OMB
and supplemented by guidance
from CISA, the Cybersecurity
and Information Infrastructure
Security Administration
under DHS.
So, my name is Jim Russo,
and I am with GSA Federal
Acquisition Service IT category
and right now the technical
lead on the EIS program,
Enterprise Infrastructure
Solutions.
Later on, I'll be
joined by Sean Connelly.
Sean is with CISA.
He is currently the TIC
program manager there,
and he was the prime speaker
during the TIC road show
that took place earlier
this year,
January, February timeframe.
And we know a lot of people
saw those either in person
or heard the webinars that
we did online, but you know,
this is pretty important
information
that we want to share.
It's something that you can
listen to multiple times,
sort of to refresh
yourself and learn something
that maybe you missed
the first time
through because there's
an awful lot
of information that's been
discussed throughout the
slide deck.
We also realize that lot
of people didn't have the
opportunity to either see
or hear the road show, you
know, when we were doing a lot
of presentations, as I
said earlier in 2020.
So, this is an opportunity,
we thought,
to put this down on video,
record it, and have it available
for folks to look at
pretty much anytime.
So, with that, I want to
launch into the agenda
for the briefing today.
I'm giving the welcome
and background now.
The agenda slide shows that the
next thing up is Sean Connelly,
and he'll walk through
the TIC 3 draft guidance
that CISA published
right before Christmas.
Then I'll come back and wrap up
with EIS and TIC 3 solutions.
And that is how we're
accommodating potential
solutions under the
EIS contract.
And then, Q and A, well
that's what we had for folks
that were watching us in
person, but maybe we'll throw
out a couple questions
for ourselves to answer.
Okay. So, let's go to the
next, that's background,
and then after that, just
to give you some backdrop
on slide four, the TIC Policy
Update Memo and Guidance.
The policy was out in draft
for a long time, most of 2019.
It was final and OMB released
it as M1926, September 12, 2019.
Shortly thereafter,
CISA put together a set
of TIC-free guidance documents
and published them right before
Christmas, as I said earlier.
There are nine documents in
that tranche of documents, so,
it's a lot to go through.
They, CISA that is, opened
up a RFC or RFI period,
which closed earlier February.
Those comments were
received in good shape,
and I know that the team
is looking at them now.
Subsequent to that, we
at GSA released a TIC update RFI
late February, and we're looking
for comments to come
back from industry
and agencies we've shared that
with by the end of March 2020.
Realizing some of these
dates may have gone
by by the time you watch this,
but that's right now the
plan we've been following
since the OMB memo was released.
So, why do you ask, is
GSA even involved in this.
It's primarily OMB
and DHS, correct?
Well, that is correct
to a point.
DHS has a lead role in managing
TIC pilots, approving use cases,
and collecting feedback from
agencies and talking about,
well, with a new governance,
what does compliance
really mean.
GSA for our part, we
are assisting or sort
of supplementing
what OMB and DHS do
from a contractual
acquisition perspective.
We are also supporting DHS in
the collection of feedback,
witness the RFIs, I
talked about previously,
and we're also tackling the
governance issue as well.
It's going to be different
than it was in the days
where the only solution
there was was [inaudible],
and we'll talk about
that a little later.
But now it's much more diverse.
Okay. So, that was just a
little bit of introduction,
and I'm going to go
ahead and turn it
over to Mr. Connelly
now, and he'll walk
through the TIC 3
draft guidance.
>> Hello everyone.
My name is Sean Connelly.
I'm with CISA.
If you could forward the slides
two more slides, I think.
There we go, and
there, thank you.
So, again, my name is
Sean Connelly with CISA.
Just a little background
on myself.
I've been involved with
TIC since the beginning
of TIC back in the late 2000s.
I was originally part
of the TIC office
at State Department in 2013.
I moved from state over to CISA,
and I've been supporting
the TIC program office ever
since at CISA as a
federal employee.
I've also been part
of the CDM program
at CISA, helped set that up.
The Einstein Center deployment
program office at CISA,
and then more recently in
2017, I was one of the authors
of the IT modernization
report to the President.
And then even more
recent than that,
the NIST Zero Trust Special
Pub that was released last year
in draft, I was on of
the four authors on that.
I bring that up, because I think
all four of those elements, CDM,
Einstein, the IT Mod
Report, and NIST Zero Trust,
are all developments of
where we are today in TIC.
So, next slide please.
So, just the agenda.
We're going to talk
about the history of TIC,
talk about where TIC is
today and a little bit
about the future of TIC.
Just a recap of what, some
of what Jim was talking
about earlier.
In September, OMB released their
update to TIC memo to 1926.
In December, CISA released
our draft guidance.
It was about or nine
different documents,
and we opened the documents up
to a request for comment period.
In January, both GSA and CISA,
we did a number of webinars,
road shows, and talking
to agencies
and different stakeholders,
familiarizing everything
with the new guidance, and
then we closed the request
for comment period.
And now that RFC has been
closed, the TIC PMO is
in the process of
adjudicating the comments.
Next slide please.
Well, go one more.
Thank you.
One more slide.
So, where did TIC come
from, what's the beginning--
oh, go back one, I'm sorry.
There you go.
To start where we are,
where we began with TIC
or how it initiated
back in the mid-2000s,
when Karen Evans was the
head of the OMB cyber office.
OMB asked a simple
question of the agencies.
How many external connections
do the agencies have?
And that opened a lot
of new discussions.
What is an external connection?
What does it mean to have
an external connection
versus my internal connections?
But in the end, the
number that came back
between all the different
agencies was well
above what everyone expected.
There was over 4000
external connections.
And both the OMB and the
Agency CIO and CISO shop
and then CISA ourselves
at DHS, no one was aware
that total number of
connections would be that high.
It was recognized there was not
a parity of security policies
across all those connections,
and then, most importantly,
everyone recognized,
everyone was just going
to become more interconnected,
how are we going
to manage growth or scale?
Then lastly, at the same
time, DHS, we were beginning
to mature our authorities
to monitor
and secure the federal
dot gov horizon.
Next slide please.
So, from this OMB
created the TIC initiative
with a number of TIC memos.
The memos had explicit goals
and what we call implicit goals.
The explicit goals,
the primary one
on the strategy side was
consolidate the network
connections, those external
connection through a number
of thick access points, which
we'll talk about in a moment.
But consolidate all
those connections
into a finite number
of TIC access points.
Really what this was doing was
this was creating the internal
and external strategy of
the federal government
for the next ten years.
Beyond that was the
standardization
of the secretary perimeter.
The agencies are
required to build
out these physical
TIC access points
and the service providers build
out what was called MTIPS TIC
access points, and these were
where the agencies or providers
would have their firewalls,
IDF sensors, all their
telemetry requirements.
These were what were [inaudible]
those security perimeters.
Then lastly, it provided
a platform for CISA
to deploy our centers, our
ability, CISA's ability
to gain situational awareness
from those environments.
This is the beginning of that.
But I think more importantly
was the implicit goals that came
with these new authorities.
It empowered enterprise
CIOs and CISOs.
I remember in 2015 or so, a
deputy CIO said TIC is a hammer,
and it told me that they
understood how to use the powers
within TIC to be able
to move the authorities
or expand the authorities
of the CIO and the CISOs
to gain an awareness of
those type of connections,
what was going through
those connections,
who the people are talking to,
what was on the other
side of those connections.
Next was motivate all agencies
toward a stronger cybersecurity
posture, heard over and over
again during early days of TIC,
rising tide lifts all boats.
And that was to mean
across that dot gov horizon,
making a stronger cybersecurity
posture for all agencies.
And third, it was part of
our initial efforts to,
from the DHS perspective,
the weaken exfiltration
activities across dot gov.
Next slide.
So, the TIC 1 and then
TIC 2 iterations were
around for almost 10 years
between the two, but over time,
there was a number of
challenges that came about.
From the TIC 2 perspective,
that consolidation of networks,
it was a challenge
to move all traffic
to these finite firewall stacks.
Essentially, it was a
binary choice for agencies.
Either everything was inside,
it was trusted, and everything
on the outside was not trusted.
There was only one security
architectural model.
We recognize that the perimeter
was starting to dissolve.
Mobile, Cloud, partner networks
were all ways the perimeter was
not what it was anymore as it
was in the traditional TIC 1
and TIC 2 iterations,
and the risk tolerance
of agencies varied.
I think from before, there was
this one policy, this one model
for all agencies, we recognize
the agencies had different
models based on resources
on risk omission.
Then also, the traditional
security assets that were
in those tradition
TICs, the firewalls,
the web-application firewalls
and antivirus, they may not work
as well in these
new environments
of mobile and cloud.
It began to be recognized that
the security architectures
that emphasize the traditional
[inaudible] strategy are
inhibitors to the dynamic
access requirements of today.
Next slide.
Now we'll move onto the present
day of TIC and where we are.
Next slide.
So, the memo that we mentioned
earlier, memo 1926, was released
in September 2019 from the
federal CIO [inaudible],
tasked DHS with modernizing
the TIC initiative.
It calls for update program
guidance and use cases.
And then the focus of the
memo is on the strategy.
Where before the strategy was
this consolidation of networks,
now there's this controlled
expansion of circuits
and connections at
the discretion
of the agency CIO and CISO.
The architecture, where for the
last 10 years the architecture
was simply that traditional
TIC access point.
Now, we had the options
for alternatives,
what we call use cases.
And third, visibility.
The telemetry and
situation awareness,
both toward the agency and CISO.
What is needed for
the agency to be able
to understand what's going
on in those environment
and then what is available
or what's possible for CISA
and our situational
awareness requirements.
What you don't see in this
memo as much is governance,
and we'll talk a
little bit about that.
But the paradigm is moved
from that fixed asset
and fixed networks and
what we meant by desktops.
For right now it's
less fixed assets
and less fixed networks means
laptops maybe [inaudible] Wi-Fi.
Pretty soon we know
we're going to be
on an entirely new platform that
isn't fixed, mobile and tablets.
So, we're shifting from that
single network boundary to more
of a distributed
secure architecture.
The new policy begins
that transition
to multiboundary to trust zones.
It allows us to be more
iterative and adaptive.
It gives broader interpretation
authorities to the agencies
and also rescinds
the old OMB memos.
Next slide please.
Well, this shows the old,
what was called the TIC tax,
the cost to support
the TIC policy.
And as agencies had their
offices and their mobile users
around the continental U.S.
or with some of the agencies,
OCONUS, overseas, there was
still this cost, if you will,
for the traffic to come en route
through these physical
TIC access points.
And so the idea with TIC 3
was to eliminate that TIC tax,
to reduce the transport
cost, to reduce the latency,
meaning the time it took from
the server to talk to the client
or for the client
to talk to a server,
and last to improve
the user experience.
We recognize that the access
requirements were becoming
inverted with more users,
applications, devices, services,
and ultimately data outside
the traditional enterprise
environment than inside.
Next slide.
So, multiboundary approach.
This is the trust zones
that are discussed
in the reference guidebook that
we'll talk about in a minute.
It's important to understand
what a trust zone is.
A trust zone is an
abstract concept.
It's elastic.
A trust zone can
still be a network.
But conceptionally, a trust
zone can be an application.
It can be a user identity.
It can be a cloud container.
It can be an endpoint.
Ideally, also, when we start
talking about zero trust,
the trust zone can be
that narrowly defined,
trusted enterprise resource, the
trusted application has defined,
as outlined in the NIST Zero
Trust Special Publication.
Part of the challenge right now
is until we develop more pilots,
it's difficult to
embed the expectations
of what the trust zone could
be and the current artifacts.
But in the end, even in
a zero trust environment,
there's still something
that's trusted,
whether it's the user,
the app, or the data.
One of the aspects of the TIC
program in general is we had
to accommodate multiple
architectures.
And those multiple architectures
means agencies that still want
to support that traditional
TIC access,
would show before the TIC
tax, and then ones that want
to support more modern
environments, zero trust,
or micro segmentation.
Ideally, we want to shrink
that trust zone down as small
as possible, but
TIC 3 cannot only be
about micro segmentation
or trust zones.
We want to contract
that-- I'm sorry.
We want to contract
the attack service
to as narrow a vector
as possible.
So, this framework that
we've outlined in TIC 3 is
to accommodate multiple types of
trust zones and architectures.
Next slide.
So, now I'll go through
each of the documents
that has been released.
It's important to understand
with these documents,
these documents have been
two years in the making.
The documents can be grouped
into two different
categories, if you will.
The first one is the
program guidebook
in the reference architecture.
We consider those to be more
strategic and programmatic.
We suggest those be the first
ones that stakeholders look
at to understand
the TIC program.
And then what we consider
the more operational
of tactical documents, that
Security Capabilities Handbook,
the TIC Use Case Handbook and
Use Cases, and the Overlays.
We believe those will be the
documents that agencies use more
on a day-to-day basis.
We mentioned before about
these documents being built
over two years.
We've had multiple
interagency working groups.
We've had participation
from over 50 agencies
in those working groups.
We've also held through GSA,
Jim's team, multiple meetings
with each of the
[inaudible] vendors.
We've also had [inaudible]
and one-on-one meetings
with cloud providers,
security vendors,
and agencies themselves.
And we've also completed a
number of TIC pilots already.
Next slide please.
So, the first document
is the program guidebook.
It talks about the history
of the TIC initiative.
It gives a direction for TIC
outlined in IT modernization.
It gives core updates and
changes to the program itself
and gives an idea of how
to use the different documents
together, the orchestration
of the use cases, the
capabilities, and the overlays.
The goals were more
boundary focused,
what I mentioned
before, the trust zones.
It's not only about
internal and external.
Now, we can shrink
those boundaries
down to more trust zones
and multiple trust zones.
It's descriptive, based more
on objective and intent,
and that is about saying
this is the only way
to meet a capability.
So, risk based mean
agencies are able to employ
and secure environments using
the risk policy of their agency.
Trying to make it more
environment-agnostic means not
only for the agency's
on-prem environments.
Dynamic and adaptable, how we'll
be supporting new information
and new use cases on
a [inaudible] basis.
Automated and streamlined
verification.
How we're looking at
gaining telemetry.
Then also last, about
how the TIC program
and the Einstein program are
being decoupled somewhat.
Traditionally, the Einstein
program, known as NCPS,
has been embedded at
those TIC access points.
As we start to move toward
virtual environments,
physical centers may
not be the only way
to gain situational awareness,
and so we are starting
to both work together with NCPS
but at the same time let each
program involve independently.
Next slide please.
The reference architecture.
The reference architecture,
traditional TIC, TIC 2,
was the primary document
for the program.
A lot of the material that was
in the reference
architecture has now been split
up into other documents.
We still believe the
reference architecture is
of primary importance.
It serves as the reference
foundation for solutions.
It's being used for
comparison and lineup purposes.
It provides common
language and terminology.
It ensures consistency of
technological implementations.
It supports solution
validations.
We know some agencies use
the reference architecture
to justify their budgets
and acquisition requests.
It encourages adherence
to common standards,
specifications, and patterns.
It also defines the concepts
used throughout this document,
the trust zones that we
mentioned earlier, the PEPs,
which are the policy
enforcement points,
use of security environments,
and the management plane.
Aside from the user
plane, the data plan,
and also go into discussion
about how to secure the admins
that secure these environments.
Next slide.
The next document is Security
Capabilities Handbook.
The objectives, which you
see on the right side,
manage the traffic, protect
traffic confidentiality,
integrity, ensure
service resiliency,
ensures effective response.
What's important to understand
about the capabilities
wherein the old TIC 2 reference
architecture that was a static
list, we now have the ability
to update the capability
list periodically.
As we have new use cases and
new overlays and services,
we can update the
capability to help agencies
to meet their mission
needs, meet market trends
as the threat landscape evolves.
Next slide.
The application themselves,
the capabilities that are
in the document, they're grouped
into two different types.
We have the universal
capabilities.
[inaudible] those example would
be configuration management,
lease privilege,
time synchronization,
those are ones we
recognize are important
for most every type of use case.
We give some guidance
on those, but we believe
that those aren't the
focus of the use cases,
so we lead the guidance at
very high level and recognize
that they're still
important to be addressed.
But now we just start
putting out the use cases
to the different environments,
and we also have a second group
called the policy enforcement
point capabilities,
and these are the ones
that are more focused on
the different use case.
Right now, the PEP
capabilities are grouped
into about eight
different categories,
support applications, services,
or devices along the path.
For example, we have a
PEP capability for email,
a grouping for web browsing, and
a third one for bio protection.
What's important to understand
is not all capabilities,
not all PEP capabilities are
applicable to every use case.
We can also cross map
the capabilities both
to the NIST cybersecurity
framework and 853,
and what's different from TIC 2
to TIC 3 is PEP's
policy enforcement point
and the security capabilities
themselves can be embedded
in multiple locations and
not about just one location
where the PEPs are located.
Next slide.
The next book is the, the
next document is the Use
Case Handbook.
The Handbook itself is
only a few pages long,
and then the Use Cases,
which are separate documents,
they can be somewhere between
20 to 30 pages of guidance,
and we'll go into detail
on an example use case.
The use cases give a
description, identify the scope
of the use case, identify the
assumptions and constraints,
map out the proper
security capabilities,
[inaudible] conceptual
architecture,
and define security patterns.
Next slide.
So, now I'll go into one
of the use case examples.
When we released the documents
at the end of December,
we released two draft use cases,
and the reason we
released two was we wanted
to both show what we
were planning to do
with the use cases
and gain feedback
from the agencies before
we invested too much time
in building up the
rest of the use cases.
We wanted to hear if these
use cases gave the right level
of information, gave the right
tone, gave the right cadence.
So, right now we'll go through
one of the two use cases.
The other one releases
traditional TIC access point,
which sort of covers
what we've been doing
for the last ten years.
So, we focus on the
branch office
because this is unique
and different.
This is what's new about TIC 3.
What this does is it
eliminates that TIC tacks,
that network gymnastics that
we talked about earlier having
to route traffic back
through the TIC access point
of an agency as a branch office.
In this use case, we let
the agency show scenarios
where the agency
connects to the internet,
connect to different
cloud providers,
and because we are allowing
the agency to connect directly
to those different environments,
we now give guidance
in a way we didn't before,
which was the agency back
to the headquarters of
the campus as we call it.
Those donuts you see there,
those represent the
policy enforcement points.
And we struggled for a
while with the placement
of these PEPs, these
donuts as you see here,
in terms that we recognize
that PEPs can be put
in multiple places.
I could be the branch
office side.
It could be at the
cloud provider side.
It could be multiple
PEPs in there at a time.
But in the end, we
put one PEP in there,
just so that it shows the
conceptual architecture itself.
Next slide please.
Along with security patterns
that we talked about,
the branch office use case,
is how the branch
office can connect
to different internet
environments.
We offered three
different security patterns,
going from left to right.
The first one is if the
agency's branch office wants
to go directly to the web.
We give a number of
capabilities on how
to secure those type
of environments.
The second one is the branch
office wants to go back
through an agency
campus through the web,
and you can see the
connection it has,
both PEPs in this
location between the branch
of the agency campus and
then separate PEPs possibly
from the campus to the web.
I forgot to mention
those triangles there.
That's the management.
That's what we were
talking about before
where it gives guidance
in terms of how
to secure the management
connections for the admins
to be able to monitor and
administer those environments.
And the third option is the
agency branch office using a
CASB to go between the agency
branch office to the internet.
So, what you see here, these
diagrams are detailed out in
about 20 different
pages of guidance
between the capabilities and
the different security patterns.
Next slide please.
At the same time,
we want to make sure
that the agency understand
the side
for securing the connections.
There's also the telemetry
requirements, both for CDM
and for NCPS Einstein.
While the use cases themselves
are not focused either
on the CDM program or
Einstein, we want to make sure
that it's understood that
it's still a requirement.
So, in each of these use cases,
we also put at the end some
very high-level guidance just
about the agencies recognizing
the requirements both
for CDM and NCPS.
Next slide please.
The next one is the Service
Provider overlay handbook.
This is a draft document
that we're just developing.
We didn't have this and
released, as we mentioned,
with all of the other
documents released in December.
The reason was, as we developed
the use cases and we started
to focus on infrastructures
and service use case,
at the use cases themselves
have to be very agnostic,
have to be vendor agnostic,
environment agnostic in a way,
and we recognize that
left a gap in terms
of the service provider
services that may be able
to support those use cases.
So, we introduced
these overlays,
which creates a high-level
mapping
of the vendor security functions
to the TIC capabilities.
We addressed some of the
use case limitations,
but they are independent
in the use cases themselves
and do not [inaudible]
civic use case.
And we recognize at the
same time the mappings may
be imprecise.
The vendor security
solution may not map exactly
to its security capabilities.
The overlays don't talk about
the strength of the mapping.
They don't address
the configuration,
but it just gives a high
level idea to the agencies
about what services can be
used by the provider to be able
to meet those TIC capabilities.
Next slide please.
The important thing
to understand is the guidance
that's released from CISA, OMB,
and GSA, the guidance we
released in the documents,
is intentionally notional.
It's conceptual.
It's abstract.
It's theoretical.
Provide agencies with
flexibility they need
to interpret the guidance
to suit their requirements.
Agencies are expected to
incorporate the guidance
into their risk management
strategy.
Agencies should determine if
the protections are commensurate
with the level of
risk pertaining
to their computing scenarios.
Next slide please.
This shows how all the
documents that we just went
through work together.
The agency has the Use Cases,
that shows the different
architectures.
The Security Capabilities
will give the services,
the security services
that are required
to meet the agency's
risk management.
And then the Overlays give an
idea of the provider service
that can be used to meet those
security capabilities on top
of those architectures.
In the background, the NIST
Cybersecurity Framework
and the NIST 800-53 are
our foundational documents.
All these work together to help
the agency's risk management
decisions, the agency's
architectural documents,
their system design
documents, security documents.
Next slide please.
So, now we'll go
into TIC future.
Next slide please.
So, this is just a
subset of the total number
of documents that were released.
Again, we released these in
January, I'm sorry, December.
They are accessible on
the CISA TIC website.
They are still in
the draft form,
but where we are
right now, addressing
and adjudicating those
comments, the expectation is
that the documents
will be released
in a final form later this year.
Next slide please.
At the same time,
one of the documents
that was released was an
update to the Einstein program.
The NCPS team released
their draft cloud interface
reference architecture.
The agency will refer
to this document
for telemetry requirements
and contact the NCPS PMO
for additional information.
Again, this was released
by the NCPS PMO.
It was released at the same
time as the TIC documentation.
It had a different iteration.
You see this is volume
one of the NCPS.
This will be a separate
[inaudible] documents.
The NCPS team will be releasing
what we thought was important
for the agency to understand
how the two programs are both
evolving and what's important
[inaudible] moving forward.
Next slide please?
So, now we'll go
into TIC pilots.
Jim mentioned a little
bit about this before.
The TIC pilots have a
number of stakeholders.
They had to sponsor
an agency, OMB,
the federal CISO
Council, GSA, and CISA.
Next slide please.
Now, we'll map out the TIC
process, the pilot process.
For the federal CISO Council
will announce a data call
for pilot proposals.
Agencies will then have a
number of days or a month or so
to cement pilot proposals.
At the same time, CISA and
GSA will be providing a number
of templates to help agencies
to position their proposals.
Once the agencies submit them,
the federal CISO Council
will select proposals
for their pilots.
The agencies will then work on
their pilots, both CISA and GSA.
We will monitor those pilots.
We'll work with the
pilot agency.
Once the pilot is complete,
the agency completes
the pilot [inaudible],
we will [inaudible] the pilot
lessons learned into use cases.
We'll turn that draft use case
over to the federal
CISO Council.
We'll approve that use case
for adoption across dot gov.
At the same time, GSA, they
will add those use cases
to their service packages.
Next slide please.
The lessons learned, so we've
had a number of pilots already.
You'll hear me talk
about just pilots
without addressing
all the agencies.
We work on a number of
pilots at any one time.
We intentionally don't talk
about the agencies unless
the agencies themselves are
promoting their pilots.
For example, SBA
promoted their pilot.
The Department of Energy
has promoted their pilot.
So, we talk about them.
There's also been a
number of other pilots
that we're working
on at the same time.
And so, when we talk about
let's learn, maybe we're talking
about SBA or Department
of Energy,
but maybe we're also
talking about one
of the other ones we
haven't talked about yet.
The pilots are unique to
each agency and impacted
by the tech acumen
of the project team.
We know that pilots only
represent a snapshot in time.
We mentioned SBA before.
If we look at how SBA's
environment is today,
it'd be radically different
than the time we did
the pilot two years ago.
We recognize that when the
pilot agency proposes a pilot,
it may not use the full suite
of the cloud provider services.
And cloud provider
differentiators result
in customized pilots.
It may not be adaptable
to broader use case,
so this where I mentioned before
about the use cases
themselves are agnostic.
But we have to make sure when
we're making these use cases
that doesn't focus on any one
particular cloud provider.
The pilots have been
susceptible to delays
that may prolong both the pilot
and use case development
process.
Next slide please.
There are a number of use cases,
both I already mentioned
the OMB memo
and ones we've already discussed
as potential ones I mentioned
earlier on the left side.
The ones that were
mentioned in the OMB memo,
the traditional TIC and the
branch office we released
as draft use cases.
But we are still
responsible also for building
out infrastructure as
a service use case,
software as a service use case,
email as a service use case,
and platform as a service.
And now also remote
user use case.
At the same time, we know
there's [inaudible] Zero Trust
use case.
We're talking about to OMB
about maybe mapping
the Zero Trust use case
to the remote user use case.
This is outlined in OMB's memo.
Also, there's interest
in other use cases.
Internet of Things use
case, partner networks.
When an agency is talking to
a bank or maybe a research
and develop or to
universities, how to build
out those connections securely.
Also talking to the [inaudible]
team about maybe building
out one unique to the managed
services but part of EIS.
And lastly, one we've heard
for a long time is
unified communications.
What used to be instant
messaging, if you will.
Now, with the type of
communication solutions
for today, how agencies can
build out secure connections.
Next slide please.
I'm going a little bit
on TIC 3 and Zero Trust.
But we recognize that there's
been independent Zero Trust
activities going
on for over a year.
We know that the enterprise
perimeter is no longer
single location.
As services move
toward the service edge,
unless were the central
hub, LAN services will begin
to offer more security services.
The trust zones in
our guidance aligns
with the trusted resource
in that Special Pub.
At the same time, we know the
trust zones themselves need
to be flexible to support TIC 2.
We believe the TIC
3 guidance aligns
with the Zero Trust
goals objectives.
For over a year now,
OMB, NIST, GSA,
and ourselves have been
meeting with agencies and vendor
on different Zero
Trust solutions.
We think there's enough
crucial mass to begin
to formalize the Zero Trust
activities toward TIC 3,
but we also recognize that
Zero Trust is not a complete
enterprise solution
[inaudible] federal enterprises.
Next slide please.
So, we wrap up here.
We recognize that data centers
are no longer the center
of the enterprise.
The federal enterprise
of tomorrow will
support more work off
of the enterprise
network than on it.
More workloads are
running in the cloud
than at their enterprise
data centers.
More traffic destined to the
cloud than to the data centers.
More traffic from the branch
offices going directly
to the cloud than
to the enterprise.
We also recognize the
growing enterprise needs
for this [inaudible]
computing capabilities
that are distributed and closer
to the systems and devices
that require low latency.
Next slide.
This just shows the difference
between TIC 2 to TIC 3
where TIC 2 on the left side had
that consolidated architecture
where everything routed
through those TICs.
Now, we have distributed
architecture
with distributed capabilities,
distributed security.
As we wrap up, the focus
is still on that strategy,
the architecture,
and the visibility.
But [inaudible] move the
inspection capabilities closer
to the sessions, no longer
need to reroute the sessions
through the inspection engines.
Next slide.
So, the future for TIC,
what I mentioned before
in those explicit
and implicit goals,
the implicit goals
are still relevant.
Empowering the enterprise
CIOs and CISOs,
give them the authority they
need to support their mission.
Motivate all agencies toward a
stronger cybersecurity posture.
And assessing the CISA
that would weaken the
exfiltration activities
across dot gov.
Next slide.
And with that, I'll pass
it back over to Jim.
Thank you.
>> Okay. Thank you, Sean.
There's an awful lot to absorb
there, as you figured out.
It's almost a misnomer
in my mind to,
I mean we're calling it TIC 3,
we're calling it TIC update,
but you know, TIC 2 was in place
for an awfully long
time, nearly a decade.
And you know, the pace
of innovation there
was pretty slow.
With the explosion of
services capabilities moving
to the clouds and some
federal agencies going ahead
and starting to move their,
you know, their operations
into the cloud, the previous TIC
2 solution set, although a lot
of agencies are still using
them, are obviously strained.
You know, as Sean
showed earlier,
and the TIC tacks is real.
And so, again, to emphasize what
he just said, you know, the CIOs
and CISOs have been empowered,
but you know, there's a lot
of responsibility there
and a lot of questions
that each agency
has to ask itself
as it designs its enterprise
network and then how
to secure that network.
So, you know, how do we approach
that from the EIS standpoint,
and why are we focusing
on EIS so much.
So, hopefully I can answer
those questions as I go
through the last
set of slides here.
So, let's move to the next
slide, which is number 42.
These are some of the points
that Sean's already made.
You know, the typical
agency network, you know,
there's a lot of cloud usage.
There you know, may be pockets
of static enterprise networks
with a known perimeter out
there, but by and large,
a lot of agencies are doing at
least something in the cloud,
if not everything in the cloud.
So, you know, now the solutions
are more focused on, you know,
in the future securing the data,
securing, and the transport
from the agency's let's
say headquarters or premise
to cloud applications,
data centers,
and now especially remote users,
and you're seeing that now
with the COVID-19 situation.
There's a lot of
stress on the networks,
as you've really energized,
you turned full throttle
on remote users.
So, you know, now
transport and the security
of that transport is
very important and access
and authorization to get to
the cloud tools and datasets.
So, it requires proactive
network management
and information sharing
going forward.
You know, that's one of
the things that, you know,
we've tried to foot stomp on
in our contract requirements
where we're really looking
to our industry partners to,
you know, share vulnerability,
share solutions
to vulnerabilities, and
knowledge of attacks, you know,
how they're found and defended.
That becomes even
more important.
You know, that typically was
handled through telemetry
and as John talked
about with NCPS,
but I think there
is probably room
for that proactive network
management to reach directly
to the agency that's, you
know, buying the service
from industry provider.
Because, you know, the sooner
that everybody knows
what's going on,
the better off everybody is.
Let's move to the next slide.
A again, the focus on EIS really
is a followup to the Report
to the President on the Federal
IT Modernization back in 2017.
There was concern there that,
you know, there was many places,
many ways to get solutions
to a particular security
question or challenge.
And it was an attempt to,
well, I guess if you look at it
in one way, the agencies,
if they're doing
everything themselves,
could very likely reach
out and buy a solution set
from one provider and transport
from another in cloud services
from yet another or
maybe multiple others,
and when you start stacking all
of that up, there's an awful lot
of acquisition burden that
falls back on the agency.
Now, some of that is going to
remain, but there's an intent
to try to reduce that
explosion of contracting and try
to aggregate or consolidation
acquisition
into an enterprise solution set.
And that's really where
we want to focus EIS
as a primary acquisition
vehicle for enterprise network,
that would include IT
modernization and security
and especially TIC improvements
in the solution sets
that get delivered.
So, all along, EIS
has encouraged the use
of coming technology, such
as software-defined wide-area
networks, Zero Trust
networking, 5G,
and especially cloud-based
security solutions.
There has been actually a
question that's drawn out of
that is because, you know,
in our previous contracts,
we were kind of rigid in terms
of where a particular
service was homed,
whether it was a security
solution, let's say,
or a cloud solution, or
a transport solution.
When you're looking at
an enterprise solution,
it really cuts across
all of those.
And we tried to make EIS
flexible so that it, you know,
it's not as dependent on whether
a policy enforcement point is
provided as a fast tool or as
a managed security service.
The point is that you get
the security capability
that you need.
So, the focus is on
delivering solutions that way.
It's sort of breaking out
of the box that we were
in for some other contracts,
and it definitely is a
challenge going forward.
But, you know, we're trying to
make EIS as flexible as possible
and useful to the agencies
as they tackle both
IT modernization
and security with that.
As Sean says, we've
reached out to industry.
We've had, you know, meetings
with all EIS prime certainly,
and you know, in terms
of putting solutions
on the contract, it's
a little too early
to say how those will
totally shake out.
We developed our managed
security services area to take
into account the types
of potential solution sets
we would get in the future.
We're currently, I guess,
working with our EIS
prime contractors
through our RFI process right
now and some one-on-one meetings
to sort of work out what
would be the best way
to put those solutions
sets on the contract.
We need to really find a
baseline first before we come
up with the ideal way to
do that, but one thing
that we've decided is, you know,
we're going to do what's
reasonable for the agencies
and reasonable in terms
of are we putting things
on the contract that can be
leveraged by multiple agencies
or is the solution
set that we're looking
at just really helping one
agency or a couple of agencies?
That really is going to
dictate how we put the type
of solution sets agencies
need on the contract.
But for now, as we said for
many of our other services,
you can buy solution sets
now through the EIS program,
and it is flexible enough
to accommodate customer-unique
requirements, and you know,
we're still standing by that,
and we're still in place
and position to service
requirements that way.
Let's go to the next slide.
This is a graphic, and it
sort of places, we were trying
to figure out how we would
position TIC 3 in relation
to all of the other
things going on as part
of the modernization challenge.
So, modernized transport, we're
looking at moving from TDM
to ethernet transport
by and large,
software-defined
networks, and more of,
you know, more apparent SD-WAN.
And secure access to the cloud.
You know, how do you get that?
You kind of need all those
in place, or having all those
in place really helps put
energize TIC 3 solutions.
And TIC 3 solutions
also would enable,
or not totally necessary,
but would enable some
of the mobility and 5G
challenges and also Zero Trust
as we go forward, as Sean
alluded to with the pilots.
So, you know, TIC 3,
we kind of show it here
as the center of the universe.
It's, I guess it's arguable,
but we do see a lot of synergy
between those modernizing
technologies and TIC 3.
Both says that enabler
and enabled,
if you will, each other.
So, by each other.
So, let's go to the next
slide and talk about how EIS,
as I said just a few
minutes ago, you know,
we're telling agencies and
industry to not, you know,
necessarily wait for the
perfect contracting solution.
If we have something, an
agency has a requirement,
and industry has a
solution, let's figure out how
to do it through the contract.
And then that'll build
our set of solutions
that can be leveraged
by other agencies.
So, you've got a number
of tools on the contract
that we're planning to
use to make that happen,
primarily our managed
network services.
This would enable
SD-WAN type solutions
and secure connections
to cloud services.
In fact, we're making
SD-WAN a stand-alone managed
network service.
So, we're moving forward
in that direction.
That's modification is
in process as we speak.
Also, the secure connections
to the cloud service,
the cloud service provider
connection mod is going
on as we speak.
So, those will be more
defined requirement sets
that can be used as a baseline
both by agencies and industry,
and, you know, those will be
on the contract very soon.
Our managed security services
are defined as they were
when we awarded the contracts
in 2017, and that's based
on managed prevention service,
our vulnerability
scanning service,
and incident response services.
Some of these are holdovers from
our previous networks contract.
The managed prevention service,
in particular, was refactored
from security solutions or the
security capabilities that were
in networks, and you know,
these really do focus
on I'll say network hygiene
in terms of making sure
that software is
patched, updates are put
on in a timely fashion,
and threats are both found
and resolved in a timely manner.
We're keeping MTIPS.
I reference version 2.2,
which was the latest version
that was before the
TIC 3 update came out.
MTIPS still remains available.
It's a baseline package.
It's defined, as it has
been defined in the past,
thru version, the
reference architecture 2.2
that CISA had put out.
It's still useful, we
think, in certain situations
where an agency still has
maybe a premise-based segment
that they want to
apply MTIPS to.
It can still be used, you know,
that TIC tacks though becomes
more and more onerous as more
and more cloud services
get used.
And we see it sort of as a
stepping stone for agencies
that are trying to
modernize, they're trying
to upgrade their security
posture, and they're trying
to transition from networks
to EIS all at the same time.
Very difficult triad
to navigate.
And, so we left MTIPS in there.
It's maybe not the best
solution in some cases,
but it is a stepping stone
into more modern TIC solutions,
and so for that reason it
remains in the contract.
SaaS based tools.
I sort of mentioned this
before or alluded to it.
We see many of the solutions
that are going to be applied
to the TIC and likely to
Zero Trust as a SaaS tool.
It'll be a cloud-based tool.
And of course, the fed ramp
certification will apply
to those.
The EIS contracts mandates
that any cloud solution,
whether it be SaaS or
[inaudible] infrastructure has
to be fed ramp certified to
be delivered on the contract.
So, that's our tether
into cloud.
So, you can see there,
there's a lot of places
that solutions can borrow from
when being put together on EIS.
And we have the flexibility to
update and add new capabilities,
new services, as we go along.
Okay. Let's go to
the next slide.
It'll be number 46.
One of the things we do in
terms of our transition efforts
from networks to EIS and
modernization support
with agencies is we have
a solicitation assist tool
that we offer to agencies
in terms of we'll work
with them using the tool, which
basically spins out a template,
a contract template, and a
questionnaire for agencies
to basically sort of determine
what the requirements are
and map that into
an EIS solicitation.
So, we've extended that
basic tool or template
to include modernization such
as SD-WAN and TIC going forward.
Now, we're sort of piggybacking
on what Sean's team is doing
in terms of putting
out the TIC guidance.
We've overlapped, I would
say, a little bit in terms
of their [inaudible] idea, and
we've also wished to borrow,
or we will borrow heavily
from the security capabilities
and the PEP capabilities
that are
in the TIC 3 guidance
documents as part of this tool.
So, that is being put
together as we speak again.
It's nearing finalized form.
And, you know, with this tool,
we can help agencies customize
their requirements and map them
against TIC use cases
that have been established
or will be established
through a pilot later on.
Okay, let's go to the next.
Okay, the template, as
I said, borrows heavily
from the TIC 3 guidance.
I guess I shouldn't
really say it that way.
It really employs TIC 3 guidance
and supplements it so that
when agencies are developing
requirements we can refer
to the TIC volumes
three, four and five
and in reference
architecture as well,
as Sean already walked
through, and apply them
to well how would you overlay
that, how would you map those
to an EIS solution or
an EIS solution set.
So, we're using that concept as
well to try to get to solutions
that agencies can buy
on the contract and ways
to offer those solutions
on the contract.
Okay. Let's go to the next.
All right.
So, I've mentioned
that we're in process
of doing a lot of things.
So, what are we doing
with the contract?
First thing is, obviously,
we've got to update the policy
references in the contract.
When it was delivered or
awarded, I should say,
everything pointed back to the
OMB memos from 2008, 2009, 2012.
Those have all been wiped away.
We're referring to the latest
memo that came out in 2019.
We're updating the cloud service
provider connection feature.
Right now, this is a feature
on our transport VPNS service.
It could be extended in
the future to other types
of transport, but for now, we're
leaving it there, and we're sort
of leverage the existing
services that have been
in place already that
use that capability.
We're updating it and right
now that modification is
out basically working directly
with the EIS primes to get
that on their contracts.
SD-WAN availability
as a defined service.
As I said before, SD-WAN
could be delivered today using
existing services, but
we're going to define it
as a separate managed
network service with a set
of standard requirements.
That will be coming
along shortly.
That's being developed.
And then, you know,
we want to flush
out the TIC 3 solution
areas on EIS.
Because I keep saying TIC 3.
It's very easy to say
that because it follows 2,
but it's really a
TIC solution area.
We've, you know, we're looking
at different ways
we could do that.
We could have sort of
a general TIC solution
where industry can put
packages together and offer them
to agencies, or we could
them by use case, you know,
get a little more granular.
At some point, you know, there
may be too many use cases
to do that effectively.
So, we just have to sort of
sit back a little bit on that
and wait and see how the
initial use cases turn out
and how they're leveraged
between
or among agencies before we
make a final decision on that.
But we will have a way to
have those solutions developed
through the contract either way.
I've talked about our RFI
out to industry in March,
that since we're still
in March it's still open.
We have in this slide an
email address where comments
and questions can come
in regarding this,
sdintake@gsa.gov.
So, we'll respond to anything
coming in through that and add
that to the pool of
comments and questions.
Let's go to the next.
So, we're to the end.
I just wanted to use
this just real quickly.
We do, we have been
getting a number
of questions regarding
the MTIPS service,
and one of the questions was,
well, can we still get that?
The answer is yes.
And another one is, you
know, what if you have to,
what if you decide
to modify MTIPS?
And here our current stand is
that we want MTIPS baseline
to stay as it's currently
defined.
If CISA comes out in the future
and redefines the MTIPS
security stack let's say
or no longer requires
that Einstein be part
of the MTIPS security
stack, then maybe we go back
and we edit MTIPS and it
becomes, you know, MTIPS update.
But for now, since the agencies
have relied on the MTIPS to work
in a certain way,
the requirements still have
not really been rescinded.
The policy says that for the
traditional TIC baseline,
MTIPS can be leveraged.
So, what does that mean?
In terms of the contract,
we've taken that to mean
if it's MTIPS, we're going
to use the MTIPS requirements
and solution as it's
defined in the contract.
If it's MTIPS like, it's MTIPS
with a shorter security stack
or an expanded security stack.
We want to put that in our
managed security services
basket, just for contract
management purposes,
really nothing else.
So, that's where we are on that
particular question right now.
I've also gotten some
on are the use cases
in the policy the only
ones we're going to have?
Well, I think Sean's already
answered that question,
showing that there's
possibilities
for many use cases.
And again, one early one we
had was are TIC solutions going
to be seen as cloud
based or security based,
and the easy answer to that
is really they're both.
So, with that, I want to
thank Sean for joining me.
Thank you for listening,
and hopefully you gained
some knowledge from listening
to us talk for the
last hour or so.
And we look forward to
your input and questions.
So, good day.
