This content summarizes recent and upcoming updates to the FedRAMP program, focusing on process improvements, new mandatory requirements, and evolving guidance for cloud service providers (CSPs) to enhance transparency and security within the federal government's cloud ecosystem.
Mind Map
انقر للتوسيع
انقر لاستعراض خريطة الذهن التفاعلية الكاملة
piece. Um, but for those of you uh
who've been here before, you know the
spiel. Um, for those of you who haven't
uh been here before, uh you know, the
first thing we always do is talk about
our legal disclaimer. Um, and it it is
shortened greatly since I think our
first meeting, but uh here it is uh in
its entirety. I am communicating uh
today in my official capacity on behalf
of Fed Ramp at the General Services
Administration. We hold these meetings
to enhance transparency between industry
and Fed ramp so that we can open a
dialogue and share new developments.
Nothing that we share constitutes
business advice and any reference in
this conversation to any specific
commercial product or use of any
corporation name is for the information
and convenience of the public and does
not constitute endorsement,
recommendation or favoring by the GSA.
That being said, um we will move into
our agenda today. Um if you are tracking
or have been tracking uh the the uh
changes on the website or if you follow
Pete on LinkedIn, you know there's been
a lot of changes uh that have happened
uh over the past few months. There are
also a lot of changes getting ready to
happen uh you know in terms of uh just
administrative changes to the the
community groups um which if you're here
you at least know some of the changes
that have happened um the there's been a
lot of updates to our website uh the
documentation um um and we are getting
ready to release a few uh Rev 5 balance
improvement releases and somehow the V
dropped off this uh uh agenda so
apologies on that and then we are going
to talk some of the upcoming RFC's which
is um when I think most of the will come
out to Pete. Um uh but without further
ado, let's talk administrative updates
and over to you Ryan.
>> Thanks Paul. Um so if uh folks joining
can't figure it out already, we are uh
using Google Meet for our first meeting.
Uh we have a reserved uh number of
licenses for Zoom and so we've moved
over to Google Meet. So, I apologize as
this is our first meeting and we're uh
starting to figure out the features,
turn on and off and let people in. So,
if you hear some buzzing or dinging,
it's us letting people in the room. Um,
all of the meetings are going to be
posted on our uh Fed Ramp uh community
groups page and uh these are recurring
meetings. For the Rev Five meetings,
they will be the first Wednesday of
every month. um you'll be able to
download the IC file and save it to your
computer. If we have any meeting
changes, we will use that page update.
Um so if for some reason you join and
there's no meeting, please go to that
page and take a look uh to see if the
meeting is still happening. Uh another
administrative update, we have the emoji
features on. We turned off the group
chat just to uh keep the live
conversation down, but we do have the
Q&A enabled. Uh, if you're looking to
ask questions, you can click the three,
sorry, the nine dots in the lower right
hand corner, scroll down to the Q&A
section, and we'll take a look at your
questions and, um, as they come in, we
do have that feature turned on where we
can, uh, go through and make sure that
we're only posting questions that are
relevant to today's meeting. Uh, so
we'll be managing that throughout the
meeting. Um, with that said, uh, let's
pass it over to back back to you, Paul. Correct.
Correct.
Yes, it is back to me. Um, I'll talk
briefly here about a lot of the updates
that have uh um gone on over the past uh
oh man three three three-ish months. Um
right, first and foremost um uh we did
uh major process documentation updates,
right? That includes our CSP
authorization playbook, agency
authorization playbook, and continuous
monitoring playbook. Um we had a lot of
uh as we were delving through these,
right? not just um uh documents embedded
in these playbooks, but there were
documents linked to other documents with
documents embedded and and it really as
we started to update these, it really
became prevalent that we've had this uh
uh monstrosity of documents uh link to
each other and uh we we we had a really
big concerted effort over the past few
months to kind of consolidate all the
all the information that was out there
um consolidated into into kind of three
standardized playbooks and uh uh and you
know change some of the visualization
associated with it as well. Um so in I
think December we released um all three
updates to the playbook. Um over the
last few months we've gone to webize
them. So if you go to the documents now
they're actually web pages that just
helps um us from a configuration
management perspective. Um and when I
talk levels of consolidation, right, if
we just talk about the continuous
monitoring playbook itself, um that we
consolidated, I want to say 13 uh um
both documents uh uh that were
individually uh published um into that
continuous monitoring playbook. So it
was a pretty pretty hefty consolidation.
Like I said, they're all webized now. Um
so you can go there, they'll they'll
kind of stay updated. Um each document
not just was consolidation, but we added
the links to all the newest templates.
Um once again I'll I'll talk here in a
second about released some of the
updated templates in the next section.
Um we uh incorporated a lot of the
changes from the BS um a lot of the
nomenclature that we're using within the
BS as well. You'll see that prevalent uh
throughout the documents. Um uh we also
updated to get rid of a lot of the
things that have since gone away things
like the jab. Um um so there's no more
should be no more references to that.
Like I said lastly, we're turning them
into kind of living web pages. Uh if you
do see any errors, please feel free to
uh reach out to info at uh we are it is
a very small team that we have. So it
will most likely go to one of the four
of us uh sitting here with you today. Um
and we'll make sure we get it updated.
Um when it comes to it's updated, you'll
see that we released updates to SSP
appendix A, the SAR appendix B, um our
Fed Ranch control baseline, and those
really covered um a few changes uh from
the Fed from Fed Ranch perspective when
it comes to um expected controls um uh
really along the lines of encryption and
segmentation things that we've had RFC's
out for, right? like SC7 um as you know
um so those have all been changed as
well um and then uh we also in the
security controls baseline just to kind
of alleviate some of the questions that
we get uh pretty regularly at info at we
also added a column I want to say it was
column J um that identified those
controls that have some sort of
continuous monitoring or some sort of
periodic requirement um and those
periodic requirements are identified as
well in that uh and lastly u when we
talk about a lot of the updates
kind of the the previous MMO that we've
had is that if we've ever released a
template, if we've ever released a
document, if we've ever released um
website uh update, we've always archived
those and made our archives uh public.
Uh that's kind of caused a lot of issues
in terms of um old templates being used.
Even though it's it's blatantly stated
archive um we still get a a lot of old
stuff in the new MO as to you know if if
the content has no relevance we are you
know keeping our archive um so that we
we in lie with all the records
requirements but um we are not making
those public anymore right once once
content is no longer relevant or is
superseded by new guidance it's no
longer publicly accessible um right I
think over the past few months we we've
dropped 160 something um archived uh web
pages whether it's from the federal ramp
archive from the facts um so yeah you
should see a lot of updates and uh like
I said lot lots of action going on uh um
and lots of work during the the shutdown
um so with that I will pass it to Nicole
I believe
>> oh this one's over to me I think for the
road map I'll say it um so we just like
to flag as always a reminder uh that we
have a public road map although Normally
part of my spiel is that we update this
every two weeks at each of our sprints
except for as I went to grab the link
for this. I realized I forgot to update
it over the weekend. Uh so it has not
yet been updated for the end of the year
sprint. Blame New Year's holidays,
vacations, etc. We'll make sure to get
that updated today. Um this is intended
to be a place for that are interested in
paying attention to what's going on with
Feder to go on a bi-weekly basis and see
what's changing. Um I I dropped a link
to the full repo rather than the
specific board because you can see
summary information about thunderrap.
You can look at the progress.md which
shows all of the changes to tickets. And
not everything that we work on is going
to be listed here. Uh but in general
this gives you a good idea of what we're
focused on and what we are trying to do.
Um it is really intended to be a routine
regular resource for people to visit.
Um, I tend to do updates either uh
Fridays at the end of sprint or
sometimes over the weekend. We won't
talk too much about that. Uh, so make it
a point to check it out Monday every two
weeks. Put a thing on your calendar, see
what's changed, see what's going on with
Better so you always have the latest
because we are always responding and
changing to various things going on in
the real world.
Um, so with that, we're going to have
we're going to shift this over to Nicole
to talk a little bit about the balance
improvement release uh releases that we
have queued up. Um, actually before we
do that, I'm going to answer one of the
questions related to optional balance
improvement releases. And there was a
question here from um,
um,
wait, where did I go? Where did I see
it? Have sworn I saw one about that.
Ah, if a CSP wants to adopt one of the
balance improvements for Rev 5, do we
have to have agency explicit approval or
is it enough if the agency says it
should be fine and does not object to
the adoption? So, this is a complicated
question because it's going to depend a
little bit based on your agency, your
risk appetite, your positioning, etc.,
and changes within the Feder
environment. Right now, if a balance
release is in uh beta, so it's in open
beta or closed beta, then we expect you
to at least check with your agencies to
make sure that they are not going to be
really pissed off if you adopt it. Uh we
are actually going to be uh creating
some formal communications and having
some uh votes with the federant board
this month to formalize these as things
that agencies are supposed to follow.
We'd like this to move towards a world
where because the balance improvement
releases are designed to also simplify
the agency workload that agencies will
actually be encouraging their cloud
service providers uh to to do this
starting with the significant change
notification process. But for now, you
are best off as always having
communications with your agency. I will
also always point out you need to talk
to your lawyers uh about any contracts
that you may have in place because some
agencies may have established a contract
with you that required certain things
that are different than what Feder
requires and therefore what Feder says
doesn't doesn't go because you committed
to something else. Um but in general
explicit approval is not intended. The
the intent is that these changes apply
across all of the government for all of
agencies. And if you have problems with
one agency that is preventing you from
adopting something, but you have other
agencies that want it, then that is not
in the interests of the government for
you to not to adopt it. You should adopt
it and coordinate with everyone to to
make that happen. All right. So, let's
talk about mandatory
mandatory
uh improve or mandatory balance
improvement releases with the federal
security inbox. Nicole Paul, next slide.
>> Cool. All right. Um, there is an easy
place to look up all the balance
improvement uh releases putting out for
Rev 5. It's on our documentation
website. Um, nicely organized for you.
Um, broken down by mandatory and
optional so that you can keep track of
where we are. Um, please go familiarize
yourself with all of the balance
improvement releases that we're putting
out. Uh some of them are optional going
into open betas. So you can participate
with the um with those as is convenient
for you. Um others are mandatory. So
let's jump into some of the mandatory
ones. Um one which is active right now
and one which is coming up in a couple months.
months.
Paul, can you shift the slide? There we
go. All right. So the currently active
mandatory balance improvement release
that we have for REV 5 is the Fed RAM
security inbox. This one uh went into
effect this week. So we are expecting
every cloud service provider to maintain
an operational security inbox that we
can email when there are important
FedRAMP updates, important security
updates that you need to know about. Um
when SIZA releases an emergency
directive, often we have follow-on
requirements for cloud service
providers, agency customers. That's
where we're going to be sending all of
that information. Um, we realized after
SIZA had a couple emergency directives
over the fall that not all cloud service
providers were um checking that their
security inboxes a work and b were
receiving email and like actually doing
something about that. Um, so we made it
mandatory. So now we are going to be
testing your security inboxes. Uh you
can check what you have listed as your
security inbox by looking at your
marketplace listing. The security email
you see that is on your marketplace
listing is the one we are going to be
using unless you send us a different
one. So uh make sure those are up to
date. We uh are planning to test that in
February and then go read the actual
documentation because there are some um
potentials for corrective action plans
and everything else if we don't get
responses based on the tests or any real
security notifications that we need to
send out to those uh those inboxes.
>> So, let's talk a little bit about what
that looks like for everyone because
this is one of those things where uh it
shouldn't have to be a requirement. Um,
and it's really unfortunate that we did.
Uh, but at the same time, it's really
important and we really want to make
sure that everyone is tracking to it.
So, as Nicole said, the basic
requirements you come through here is
that you have an email that we Fed Ramp
can communicate with you on behalf of
the government and that you will receive
and respond to. If if that doesn't
exist, then ultimately you will lose
your Fed Ramp authorization. There's no
excuses for this. There's no
justification. If you are if you do not
have a way that we can communicate with
you, you cannot have a Fed ramp
authorization. Like that should be
simple and obvious and no one I think
should disagree with that. Obviously,
you need to be able to hear from Fed
Ramp. Now, the cool thing about the Fed
security inbox is that it's actually the
first set of new requirements. In fact,
the first set of requirements in a long
time that actually has requirements
explicitly for Fed ramp for us. And like
this is our way of transparently
communicating how we're going to go
about doing something and what to expect
from us. And it includes things like we
have to use properly identified email so
that you can don't have to worry about
someone pretending to be Fed Ramp
because if you get an email from
fedramp.gov, you know it's an email from
fedramp.gov. It includes clarifications
about how we will tell you exactly
what is happening and what we expect you
to do. So for example, when if we do a
communication out to a cloud service
provider that we say, "All right,
there's an emergency. We need to know
this about your cloud service. It's
going to be very clearly labeled as an
emergency." And it will include a very
clear le list of actions. You must go
fill out this form. It will include um
this date. It will include very clear
corrective actions. If you do not fill
out this form by the state, this will
happen to you. Um the intent of this is
to create a like contract between us
that enables you to respond to us with
clear ways and enables us to be really
clear about emergencies.
I just want to be really like this is
not an opportunity for Feder to bully
you. We are not going to be jerks. We
are not going to send things on Saturday
for no reason to see if you respond and
things like that. Uh but we do have very
strict requirements and one of those is
response times. We expect cloud services
to acknowledge and respond to these
actions as if they are emergencies if
they are an emergency.
For high impact service providers that
response time is very very very fast.
Um, we actually received feedback during
the uh RFC process on this that that
seemed unfair. And I have to admit I uh
one of the very few times that I
completely ignored public feedback
because if you want your cloud service
offering to be capable of being used in
event where a problem with your cloud
service can result in a loss of life,
then you need to respond to an email
from us within eight hours. And I don't
think that's unreasonable. If you can't
do that, you should not be a high. In
fact, I wanted that to be one hour, but
we decided to be a little nice. Um,
maybe we'll improve it in the future.
So, what does implementation look like?
Well, actually, first of all, and those
requirements are less for moderate and
low, especially low. Like, we understand
low impact. You're not going to have
24/7 on call over the weekend, things
like that. That's fine. It should be.
You're low impact. Nobody's going to die
if there's a problem with your service
for three days. So, you don't have to
necessarily respond that fast.
When it comes to how we're going to test
this and what happens next,
the default is that every quarter we're
going to analyze this. We will do that
by sending out an emergency test. That
emergency test will go to every cloud
service provider to the email that we
have listed, either the public one or
the private one if somebody has
requested a private one for us. It will
include a link to a form and there will
be instructions and you will be expected
to click that form, follow the
instructions, do the thing. None of this
will be unreasonable. There will be no
like wild abuse chases just to see if
you can do it. But like you will be
asked to do that stuff. Uh the first
emergency test there will be no
punishment if if your security inbox
doesn't meet the requirements etc. Um,
that's I mean it's not okay, but like it
is what it is. We're not going to you
immediately. What we will do, however,
is publish the results of that test for
every cloud service provider. That means
there's going to be a chart that shows
how quick people responded based on
their impact levels and it will have
your cloud service provider. If you are
hyperscaler number three and it took you
four with a better app high and it took
you four days to respond, you're going
to look really bad in public. So we want
you to get in front of this in the
future once it becomes a formal thing
and there is no more grace period as we
do these quarterly tests. We will
publish this as a security metric within
your Feder authorization. So it is very
important that people be responsive to
these emergencies in general. Again,
aside from the quarterly tests, you are
unlikely to receive an emergency request
from Fed Ramp unless there is an
emergency directive, some intelligence,
or other related stuff. We don't plan on
abusing this, so don't worry too much.
I am guessing that there is going to be
some questions related to this. So,
we're going to I'm going to look through
and see if we can address some of these. Um,
Um,
>> yeah, I've seen some of the questions.
Uh, so somebody's asking what the level
of effort in responding to the security
inbox test is. Pete covered that a
little bit. We are not expecting this to
be a huge lift for you. We just want to
make sure that there is somebody at the
other end of that inbox that's
monitoring it within the time frames
required by um the balance improvement
release. So depending on whether you're
low, moderate, or high, that determines
how quickly you need to respond. But it
should be very low effort just saying,
"Hey, we're here. We got it."
>> Yeah. I mean, like the classic example
is I might give we might send you a form
that says or send you an email that
says, "Go fill out this Google form."
And the Google form will be like, "I got
this email. I think Fedramp's awesome.
Please send me a sticker. Here's my
address." And then you submit it. And
then if the maybe you got a sticker,
right? Like that's that's what we're
looking at here. Um, I see a question
from Nathan about should operations and
compliance teams have access to the
security inbox. We're going to let the
cloud service provider sort that out
like yourself that this inbox is
intended to be like you are receiving an
email from Fed Ramp that if it isn't a
test, some serious significant action
may be required. It might be like you
have to tell us the uh firmware version
of all of your firewalls, right? Like
some of us have had we we've done things
like that like this is necessary. Uh so
you should make sure that's routed to
the right people and in general on the
long term we want that to be at least
routed for awareness to a senior
security official. What that means it
can be a a sock analyst forwarding it to
a senior security official etc. But we
just want to make sure that senior
officials know when Feder is emailing
your company so you don't have the
excuse of like well you emailed my stock
inbox and like nobody saw it kind of
stuff. Pete we have a followup from
Nathan. Is this for all coms or just
security incident?
>> Yeah. So, if you look through the Fed
security inbox, there's a lot more
details about the restrictions of what
types of notifications are in there.
This is an example of like of what we
very specifically did was like we
classified three types of
communications. Emergency, emergency
test, and important communications. If
it is not labeled with one of those,
then it is you respond to that email
just the way you would respond to uh an
email from us normally, which hopefully
would be pretty quick and taken it
pretty seriously, but you know, is what
it is.
>> Another question on the security inbox
email. Does this apply to coms from
federal agencies or to our security inbox?
inbox?
>> That's a great question because this in
this is an example of things changing
through the RFC process. So in the first
request for comments, we initially said
any communication from all federal
agencies. Uh we got a lot of feedback on
that about how confusing that can be. Um
and we actually went and talked a little
bit with the board and a little bit with
OMB uh to to have the reminder that M2415
M2415
explicitly positions FedRAMP as a center
point of widescale communications with
industry. Uh so we decided to have this
focus entirely on communications from
FedRAMP. So, this is very specifically
intended to be about
security related urgent communications.
Um, like that's it. And then we'll use
that same inbox for like, hey, FYI, this
new thing is going into effect, but that
will beformational and you don't have to
respond to it the same way. Agencies
can use this if you provide it to them,
but the rules for response and things
like that don't apply to agencies. you
should coordinate that with your agency
customers and provide them the level of
service that they pay for.
>> I think you may have answered this
already, but still with the security
inbox, will this test be conducted
during normal business hours?
>> Yeah, dude. Yeah. Yeah. Whoever asked
that, like I was laughing because I I
know there are there are some people
that are probably like, "Oh, we're going
to send this thing at." So, we're
actually going to I when we send public
notification that we're going to do a
test, we're not going to say exactly
when we're going to do it, but like
we'll say at some point in the next two
weeks at 10:00 a.m. or at 2 pm or
something reasonable like that, we're
going to conduct this test. Be ready for
it. So
100% business hours and no like 4:59
p.m. Eastern kind of nonsense either.
We're like I said, we're not trying to
play here. We're not trying to bully
people or mess with you. We just want to
make sure that we have a way to talk to you.
you.
>> Yeah. On that uh theme, somebody asked
how we're notifying people about the
mandatory VIS. Um, and that's part of
the chicken and the egg problem is that
like we discovered that people aren't
keeping their uh email addresses updated
on their marketplace listings and that's
how we know how to contact you. So, if
we don't have updated contact
information for you guys, you will not
get the mandatory notifications that
we're sending out on behalf of the Fed
Ramp PMO to try to tell you that there
are changes that you need to um address.
So, we're trying to put this out
publicly, putting it out on our blogs,
on our websites. We're trying to we're
holding these community meetings for
you. We're trying to email it out to any
PC's that we have on Marketplace. We're
doing our best here, but we need um
participation from you guys to make sure
that your marketplace listings are up to
date and that we have correct contact
information for you.
>> And I'm also just going to add on to
this to be really clear. It is the Feder
authorized cloud services responsibility
to keep up with Feder requirements. Full
stop. Like we do everything. We we post
like Nicole said, we post a lot of
places. We make information available in
a lot of different ways, but at the end
of the day, someone at the cloud service
provider needs to be paying attention
what Fed app is doing. At this point, I
think we've almost exhausted. One of the
things I'm considering is maybe if we
can do some kind of RSS feed that you
can subscribe to, but again that's like
requires you to subscribe to it. Pay
attention to it. So it is on the cloud
service provider. There's no I didn't
know about this. And that especially
applies to the recommended secure
configuration process which is going to
effect in March. There's no excuse that
you didn't hear about it. Um, but the
flip side is we are always delaying
corrective corrective action with grace
periods to give you that opportunity to
mess up at least once.
Um, somebody has said if you're going to
name and shame, can you also name the
three facets for plants? Yeah, I mean
just to be clear
that's actually like I I think like I've
highlighted the negative case, but like
the positive case is the coolest thing.
Like that's the security factor. Like if
you have a Fed ramp low system that's
routinely replying within 25 minutes and
that tells you something about their
posture uh you know that
>> is meaningful and you should have that
information. So everyone we're going to
publish everyone's time.
>> Um another question about in process
included in the testing. So, at the
moment, our plan is to include everyone
that is in the marketplace
in this testing so that we have this
available ahead of time, etc. Um, we
likely will not penalize anyone. We're
not going to like publicly show
statistics on folks that aren't authorized,
authorized,
>> but we want to make sure that in process
folks are also meeting these
requirements and that they have an email
that we can talk to. Um, there's a bunch
of questions about specifics. I'm not
going to go into specifics in this
because like we have a document written
down for a reason. Go look at the
document uh and spend some time digging
through it after this call.
>> Yeah, you can also put um specific
comments or questions in our discussion
posts on GitHub. We have a specific Rev
5 section for that. Um, and we will
engage uh answering specific questions
uh preferably publicly like you can
always send it info@fedram.gov
like that is a method, but if it's a um
question that would benefit from a
public answer, post it on a discussion
post and we'll answer it publicly.
>> Yeah. Um and a recent comment, this is
heavy-handed and not well thought out.
Um you're wrong. We posted public
comment on this for 30 days as required
by law and received significant
feedback. it was widely discussed with
agencies um and with cloud service
providers and we responded and adjusted
it considerably based on feedback. So if
you didn't participate in the RSC
process and weren't aware of this then
that's like a super bummer because we
really really focus on those RFC's and
that's why we're going to talk today
about some upcoming RFC's that we're
going to have to make sure that you're
aware of those and kind participate in those.
those. Um,
Um,
yeah, there's a for the private email
inbox. I think there's a form to fill
out, right, Paul?
>> Or is it just email info at?
>> Email. I think we updated it to the info at
at
>> Yeah. email info. Okay.
>> Yeah. All right. Let's uh shift to talk
about recommended secure configuration.
Uh, we've talked a lot about the
security inbox. Uh, more specific
questions again, please post on our our
Rev Five discussion post and we're happy
to answer those publicly.
uh for the recommended secure
configuration balance improvement
release. Uh this is a result of the
executive order 14144 that came out
about this time last year. Um it
requires Fed Ramp to um incentivize or
require cloud service providers um to
provide secure configuration
recommendations for their services to
their agency customers. This is going to
allow agency customer configure their
use of your services in a way that is
the most secure option for their
particular mission. So we want very
clear instructions for what those top
level admins need to look at the
settings that they need to um configure.
How do they configure your service from
initial uh implementation all the way
through maintenance uh to make sure that
they are operating your particular
service as securely as possible. Uh
there's only a couple must statements in
this um secure configuration guidance.
It's really not um there are what 10 uh
particular topics in this. So it's not
long. There are a lot of should
recommendations. Should recommendations
including things like API access, um
exportability, machine readable
configurations so that people can pull
these automatically. Um understand that
by March is a pretty quick turnaround
time frame. So that's why we made a lot
of these shoulds. Um SIZA scuba project
has some good examples of what machine
readable um formats for secure
configuration could look like. there are
some other I mean we didn't uh actually
make formal recommendations or formal
requirements of what machine readable or
um even human readable formats of these
particular um secure configurations
should look like. So it's up to you to
determine what works best for you and
your company and the agencies that use
your service. But please make it easy to
understand, easy to follow so that any
admin from any agency customer can
easily um adopt the secure
recommendations that you make. Pete, I
know you have stuff to add on to this.
>> Yeah, I mean for this one we might as
well just go right into questions um and
we'll see how quick we can come through
there's kind of a bunch of general
questions here related to other stuff
that we can address at the end, but
there was a question about the should
requirements. Like, um, should versus
must is is very simple. Don't overthink
it. Don't turn it into a fight. Don't
feel like anyone's trying to get you.
Nobody's trying to get you. Should means
you should do it unless you have a
reason not to. And if you have a reason
not to, then you document that reason.
That reason is any reasonable reason
that the CSP determines based on their
business. That reason can be it's too
expensive. That reason can be uh it it
will take me six months to do it. That
reason shouldn't be I think this is dumb
and I don't want to. Like that's not a
really good reason. Um but like it is up
to the CSP to document that
justification and it doesn't require
validation from a 3PAO or any anyone
else. We will accept that justification
as long as it is reasonable and valid.
And I know a lot of people then go,
"Have you defined reasonable and valid?"
And I say, "It is what two reasonable
people having a reasonable conversation
would agree." And then people go, "But
no, like you really need to define
reasonable." And then I go, "If you're
asking me to define reasonable, you're
not one of the reasonable people." So
that's going to create us a problem.
It's like realistically nobody's trying
to get anybody on this. like the CSP
knows and as long as the reason really
isn't I just don't want to because I
think this is stupid. I mean to some
degree that might even be considered a
reasonable reason. So focus on the MOS
requirements you you will benefit. One
thing that I will say again and again
and again as transitions we're talking
about moving past a bar and moving
towards measuring real security
decisions and the value they have. If
you meet should requirements, your Fed
ramp ranking, your ability to be used by
agencies and to meet agency use cases
will be higher. You will be more likely
to get more agency adoption and use when
you are meeting Fender app
recommendations. So, if you're okay with
not meeting recommendations and losing
out on business, that's totally fine.
And again, a lot of this comes down to
like in an ideal world, it's going to be
like RFP driven. agency is going to say,
"I want to use your product, but I don't
like that you don't do this thing, so
you I I'll pay you an extra 500k to do
this thing when we buy your product."
Nothing wrong with that. Uh, so we're
not going to be involved with like
validating any of that or or having
three PAOs fighting over it or anything
like that. Um, okay. Anything else? Uh,
yeah. Yeah. Yeah. Uh, so here's a
question about like should we post it is
enough we post it public or any other
action that we take? I mean this is very
clearly outlined in the in the
requirements which is that like you just
have to provide it. So public is fine in
this in this case. In fact public is
ideal because we want the public to use
it too. Public that isn't even behind a
trust center is is great, right? Like
there are plenty of these cloud service
providers um that that offer this. I
think the key thing that we'd ask is
that we're looking for very specific
guidance on administrative level
privileges and roles and that is is
often kind of buried in guidance and you
know some some cloud service providers
you have 15,000 pages of secure
configuration guidance and we're hoping
that you simplify that uh in this case
>> but yeah public
>> some secure configuration guidance is
for um versions of the product that the
agency customers don't have and so there
may be extra options or um a particular
configuration that an agency just
doesn't have access to. So also helping
agencies understand what is the right
configuration for them with the version
of the product they bought from you
that's going to be super helpful rather
rather than waiting through public
documentation for features that they
don't have.
Yeah, there was another question here
that like a little bit of a theme and I
and I understand this is this is tough
but you know a question about like when
when did we first talk about recommended
secure configuration standard and I want
to be clear this is another one that
like everything that Fedramp does like
this it went through RFC. So in
September we posted that we were going
to do this we asked for public comment
on it we closed that a bit later than
the typical 30 days because of the
government shutdown. Um, and then we've
been sharing that repeatedly in all
FedRAMP channels. Um, and like this is a
thing where folks need to to if you're
responsible for this, you one need to
follow all of our comms and two give us
meaningful realistic suggestions about
ways to improve that that don't create
too much of a burden for us because
right now we're blasting this stuff all
over the place and it's kind of shocking
if folks um, you know, can't find it
along the way.
Uh great question from from Dave Becket
like what if there's no admin access uh
for a product for the customer to
configure. So I want to be really clear
as we set policies we try to also use
defined terms uh in order to to clarify
specific things and the the defined
terms include sort of a um uh they're
like a a subruine that you can apply and
so when we talk about administrative
stuff the definition of that is is
outlined in the federal definitions and
it means basically the core accounts
that are used to configure the tenant.
So, if an agency has the ability uh to
to get an account and then use that to
configure their tenant, that's the
account. Um, if that's not a thing that
happens, then your recommended secure
configuration guidance is pretty short.
Um, and yeah, a great point from Lindsay
before we jump into RFC's, which is that
like better.gov site navigation is super
confusing. That is absolutely right.
There's a number of reasons for that. I
take full responsibility for that um
within the context of the current
environment. If you've followed what's
been going on this year uh with with
FedRamp, there was a a long period of
time where I as the Fed director was
doing almost all of the website updates
because I was the primary technical
person remaining on the team that knew
how to do that and I made a mess of
things because I focus on getting
information out, you know, effectively
and fast and not so much about things
being pretty. uh we were able to get a
couple of staff added to us uh added to
our team uh to help do some more
intentional buildouts and we've been
working towards um making improvements
to kind of clean up some of the mistakes
that I have made over time. Uh but in
general we are really kind of making a
mess. We're we're we're doing
construction the best way we can and
that's why again like I keep saying
we're supporting this with all this
other communication as much as possible
so that folks can keep in line and pay
attention to the new things. Right now
we are partially through a transition
from uh one type of documentation to a
different type of documentation to both
improve things and meet um like
requirements ac on the federal
government for accessibility uh for
modern capabilities etc. uh I made the
decision to do that peace meal as those
materials came available rather than to
spend six months with it in the
background and then do a big cut over
because like that is that is rough for
us uh and it's rough for everyone else.
We want you to basically know what we're
doing as we're doing it.
All right. Uh so I think that's a big
talk through here. We'll have some
opportunities to talk through general
questions in a second. Um, let's go to
the next bit, which is our RFC's,
pending release. So, y'all are going to
have a little bit of spoilers here
today. And we wanted to do this very
explicitly to make sure that uh folks
were aware. Can't tell you exactly when
these are going to get released because
uh, you know, it might vary a bit. It
could be as early as next week. It might
be some of them, it might be partial,
etc. We're not going to give you a ton
more details about this before we cut
back to general Q&A. Um, but I wanted to
give you a heads up and and have this
available so people know some of this is
on our road map and some of it we need
to add to our road map. So, start paying
attention to our site next week and all
of our media. Subscribe to our things.
Get our eblast. There's a subscription
thing at the bottom of our feder.gov
page where you can get updates from us.
Uh, you know, LinkedIn for the the Fed
thing, everything like uh the GitHub
community. Like, let's go.
We're going to release an RFC that is
going to be a all of these. Let me
actually take a moment. RFC's are
request for comments. That's we release
draft guidance before it has been
completed to get communitywide feedback.
This has two purposes. One, it signals
our intent and a thing that we have
prioritized and are working on. Uh and
two, it allows the community to provide
us with direct meaningful feedback on preddecisional
preddecisional
um processes and memorandums. Um our
process is typically 30 days. We
strongly encourage informal feedback. We
love when people are sending us thought
rather than big formal letters and
things like that. Um we prioritize
everything equally. If you're a big
trade association or if you're, you
know, uh, Jimmy420 on GitHub, we're
going to take that feedback with the
exact same uh, leverage and importance
as we go about it. We work through that
feedback with humans. I personally
review every single comment and go
through and make changes based on those
comments. And every single
process, document, material that we've
produced after the RFC process has come
out considerably differently. That said,
some of these are pretty simple. Some of
them um will be easy. Some of them are a
lot more complicated. So, let's talk
through what we're looking at. Requiring
the reporting of assessment costs. This
is something that has been a little bit
of a chicken and egg. A lot of chicken
and eggs that we're trying to adjust
right now. Like this. This is like the
the year of 2026 is the year of chicken
and egg problems. Uh Fedramp needs to
review the costs of independent
assessments in the Fed process. We're
required by law to do that. We don't
have that information. How do we review
that? The answer is we require people to
tell us that this information. This is
another example of a situation that
could be considered heavy-handed because
we're going to say all cloud serviceers
must tell us how much they paid for
assessments and some other things
related to that. But that is required in
order for us to meet the law. Uh this
RFC proposes methods for doing that that
are designed to be simple, low burden,
etc. It will include uh reporting costs
at initial authorization submission and
reporting costs during annual
assessments and having an assessor the
assessor uh provide a sign at a station
that the numbers that were submitted to
federal app are correct. Unfortunately
for route five it means a new SAR
appendix but we'll try to keep it
simple. It will only have five or six
rows in it and those are all outlined in
RFC. Uh the next one uh oh yeah actually
you know Tara so this is addressed in
the RFC but I'll just say like our our
this information will not be shared in a
deidentified fashion except as to meet
legal requirements. Um I can't tell you
what a our foyer lawyers would
consider but generally uh we have been
successful at redacting names from foya
things that that we have released. Our
intent is not to ever say cloud service
provider A paid this much from assessor
B. It'll just be
here's a graph of assessment costs. Um
okay RFC20
ref five machine readable packages. This
is a big one. We're giving you just an
initial drop here. The long and short of
this chicken and egg is for a long time.
Uh in fact in 2022 the law required
Feder to figure out how to do this in a
year which which made me like lol
because how does Feder accept documents
in machine readable form and nobody's
producing the documents in a machine
readable form. So this is requiring
cloud service providers that are
maintaining the Rev 5 process to switch
over to machine readable packages.
There's a lot to it. It's multi-page.
It's very complicated. It's going to
take a minute for for folks to work
through it. I'm not going to go through
all the details of what that looks like
here, but a key factor is that it's
going to allow for submission in uh Ocal
as well as any emergency for emerging
format that is supported by five or more
cloud service providers. And we expect
that to include things like um you know,
you can do a fork of OSCAL and you know,
make it like whatever makes sense for
cloud service that you want to use,
we're going to accept it. um agency
adoption, all that stuff not relevant.
We're not worried about it. It's machine
readable. If an agency needs a word
document produced from a machine
readable package, you can do that. The
long term is that we need these packages
in a machine readable format so that
agencies can eventually start ingesting
them. But we have to have somebody has
to lay that egg so that we can get our
chickens. And right now the egg is cloud
server starters producing machine
readable packages. Um and we're
proposing way to do that. Final thing
I'll add on that is that like everything
that we've been doing, there will be
massive massive grace periods. Um, in
fact, we have built in a one-year grace
period to this uh policy. So, um, trying
to really minimize impact.
Next, updating the Federate marketplace.
This one's going to be big. Uh, there's
more changes to it in process. The
nut of this is that
we're going to have specific labels for
FedEmp authorized services. We're going
to finally call things FedEmp certified.
Um, and we're going to do our best to
kind of confuse uh avoid some of the
confusion about authorization. I still
to this day hear people say they got a
Federap ATO. There is not and it has
never been such a thing as a Federap
ATO. There has for a period of time been
a FedAmp TATO which is a madeup thing.
That was very confusing, but it is not
an ATO. Um, and even in the law, it's
hilarious because anytime they talk
about feder authorization, they say fed
authorization, and any other time they
talk about authorization, they're
actually talking about authorizations to
operate from an agency and not a feder
authorization, which makes it really
confusing because it'll be like feder
authorization can be used for an
authorization. Like, what does it even
mean? Why is it the same word? So, we're
going to all stop referring to it as an
authorization. Um, we're also going to
allow consultants to be listed in the
marketplace. We are going to require
independent assessors and consultants to
share public information about their
pricing structures. Doesn't have to be
detailed, proprietary stuff, just
general. You're offering a service, give
us a ballpark. I expect this one will
end up like uh I think everyone
remembers California's uh law on posting
salaries for positions and then you had
companies like Netflix that would post
like salary ranges 80 to 950K for this
position. That happens. That's totally
fine. Um, but in general, we're looking
to have some big improvements there. Uh,
one thing that you'll note in this
bullet is that we're phasing out Feder
Ready, but we're replacing it with
something else. So, let's jump to the
next slide. Oh, actually, no, big thing
I'm missing. Huge spoiler.
We're adding the ability to be listed on
the Fed marketplace if you are in the
preparation phase for FedArt. This will
let you as a company signal demand to
agencies. It will let agencies
understand who is beginning to go and
get fed and it will generally allow the
federal government to see what else is
out there. Uh this is like a huge thing.
The the preparation phase is phase one
of the NIST RMF. We're very excited
about this and we think this is going to
really help us also make the case
bluntly um to the wider government. If
we see 300 cloud service providers in
the preparation phase, then I have a
much better business case to hire people
and expand the Feder security service.
All right, here's another big one. We're
going to propose
Feder program certifications for Rev
Five as an option through the year. This
will mean that if you have a Rev Five
security package
that doesn't have an agency sponsor and
you meet certain additional
requirements, including adopting some
stuff from the Rev Five balance
approvement releases, Fed Ramp will do
the sponsorship and the certification.
This is intended to be kind of a last
harrah of uh of rev of new rev 5
certifications through the year um
before we retire new rev 5
certifications at some point in FY27. Um
but we have right now enough capacity
where if people adopt some of the newer
requirements that'll make review simpler
then we believe um that we can make this
happen. Um I don't think we can do our
estimate is around 50. Uh so we're going
to see what happens with demand. Uh but
this will be a big opportunity for folks
that have put the work in and are ready
to go right now. They can spend a month
or two uh implementing some new stuff
and then have an option without an
agency sponsor.
RSC23 not not giving you too much on
this one. Um but we are going to allow
cloud service providers that have
certain external frameworks uh like SOCK
2 assessments, high trust, things like
that uh to come into the Feder
marketplace as a special designation of
FedRAP authorization for negligible use
risk cases uh negligible risk use cases
uh and pilots. That's going to allow
folks to kind of test the waters a bit.
Uh then we also have a pending RFC about
Feder's trademark usage. This one is is
something that OGC has been working with
on us for a while. It's going to include
all sorts of stuff. Uh the main thing is
that it both tightens and restricts the
trademark usage in some ways while
loosening it in others. So, for example,
and this is all not necessarily going to
be in the final RFC, but some of the
things that that we're pushing for and
we're looking at and we're discussing,
uh, are things like if you do say that
you're Feder authorized, you will have
to link to the marketplace, uh, to show
your actual listing. This is something
that's a pet peeve of mine. Even GSA
does in press releases, we say something
Feder authorized, and I'm like, is it
though? Like, I don't know. Um, we're
also looking to clamp down on the
trademark in in some areas like it has
always been a trademark violation to use
Fed ramp or a Fed ramp similar word to
appear to provide a service that is
similar to Fed ramps. Uh, just like you
cannot make a company that uh instead of
being called Pepsi Cola is being called
Nepsi Cola and also sell cola. Like that
would not fly. Uh, so we're going to
clamp down on that a bit. And my hope
and dream, personal hope and dream is,
uh, we're trying I'm trying to get
permission to open up the trademark just
in general for swag so that we can make
it really clear that if you get FedEmp
authorization, you can make yourself a
cool t-shirt. And uh, you know, if you
want to just like get yourself a mug
that says I I barely survived a Fed ramp
audit or something, like you can do
that. Nobody's going to shut down your
Etsy store. So that's what we're looking
for on that. Um, all right. So, I that I
took more than I thought on on those
because I'm really excited about these
RFC's and I hope that you read through
them all and we're going to release some
short form like uh you know maybe 10 15
20 minute videos about each RFC with
some additional background as well and
I'm super excited about them. So,
there's a bunch of questions that have
come through throughout this
conversation, some that we put off and
with only four minutes left, we're going
to crank through on a lot of different
things. So, I'm going to start here at
back at the top. uh updates on when CSPs
have a status of in process review will
be finalized. As of last quarter, our
final review process is under 30 days.
When an agency completes an
authorization, something moves in in
process and goes to FedRAMP, it is
authorized on average in under 30 days.
If something has not been authorized
since July 2025, then most likely there
is a problem with that cloud service and
it is in remediation.
So, it has nothing to do with us and
everything to do with them, but we are
hitting 30-day reviews. That is our
target and that will continue to be our
target. Um, feedback on the URL pages
and all that stuff changing. The I
totally understand. I totally feel you.
The best thing that I can continue to
say is that you should not be
bookmarking and downloading specific
documents. Like, for now, go to the
page, find a document that you're
looking for. That's the best way to
navigate this uh for here and forever.
Things will change. It's a modern
internet. Like we we got to do it. We
can't just like constantly. We did try
to create a lot of redirects as we
change stuff around, but sometimes it's
hard. Um question on the vulnerability
manager open beta. There's language on
the open beta that says CSPs must plan
to address all requirements by the end
of the beta. Is this intended to mean
that the new standard will mandatory for
all Rev 5 CSPs? No. any application
within or comment like that within such
a thing is referring to part to people
that are using it. So it means any cloud
service provider that is participating
in the beta should plan to adopt all of
the requirements by the end of the beta
period. Um
well there's a lot of questions here. Um,
Um,
>> I'll throw another plug for the
discussion posts. Like that's where you can
can
>> Oh, yeah. That was actually like like we
are in GitHub discussions all of the
time. Like that's the place to do it. We
prefer that over info at because it is a
public forum and other people can see
the answers. Like then I regularly tell
people that send me a personal email at
pet.fedap.gov, which anyone is welcome
to do, but I regularly would tell people
don't send this to me. post this on
GitHub so that I can answer this so
everyone can hear it. Um there's a
question about assessment cost
formulation. Uh you check out the RFC,
but general I think it's pretty clear
that um you know you know how much you
paid on an assessment over the last year.
year.
>> Um question about how soon after RFC's
are closed can we expect these to be
requirements? It changes all the time,
dude. We got one one thing that went
through like three different RF like the
VDRM through like three different RFC's
before it came the VDR. Uh so like you
you gotta you gotta pay attention and
see what's up. Uh what we do do is if
you go to federam.gov RFC's right now
anytime we finalize uh an outcome from
one such as create a formal document,
we'll put a note there that says like
this is what's happening with it. Uh
when will these RFC's be on the website?
Figure it out. You're going to have to
wait and see. Subscribe to our list serve.
serve.
>> Yeah, subscribe, like, ring the bell. Um,
what else have we got? What else have we
got here? Uh, what where's the URL?
Better.go RFC's. That's pretty simple.
Um, further considerations between DoD
IL and phasing out Rev 5. I feel like
the DoD thing is a great way to end end
this conversation. um our intent. Let me
be very very clear. I have said this
again and again and I understand that um
this isn't a promise I can make and I
understand that it's complicated and
hard u but at this time Feder has no
intent of fully turning off Rev 5 as as
a path for existing authorizations.
rather we plan right now by the middle
of FY27 to phase out Rev 5 or new
authorizations, but folks authorized
before that will have the ability to
continue to run Rev 5 uh indefinitely u
as they see their customers leave and as
they see folks switch to 20x B
authorizations and other cloud services
that provide more security uh more
validation and and more uh modern easier
to follow circumstances. Uh when it
comes to the DoD and Rev 5, we don't
know what the DoD is going to do in the
next six months. You don't know what the
DoD is going to do in the next six
months or 12 months or anything around
this. Um we work with the DoD and DSA.
We have DoD on the Feder board. We are
always in alignment. Uh DoD strongly
strongly supports Feder 20X for the
commercial use cases that 20X is
designed for. There will always be a
different expectation from the
Department of Defense for things that
are higher impact and that are a bigger
deal. If you didn't see uh if you're not
if you don't follow me on LinkedIn, I
recently posted a quote from a report
from the year 1990
that was uh three years after system
security plans were first kind of really
required. Um and NIST did and the NSA I
believe this is so old that NIST wasn't
it was like the Bureau of Standards at
the time or something um they did a report
report
where they reviewed all system security
plans submitted across the government
civilian agencies and DoD and 35 years
ago in that report they noted the DoD
did not follow the same processes that
the rest of the civilian government followed.
followed.
And so when you bring up this, you are
talking about solving a problem that has
been the case for more than 35 years. It
is not a problem that I expect Federal
will solve and I is not a problem I
expect the DoD will solve. I think as a
industry we need to be aware of the fact
that the DoD will have different
requirements and we'll do our best uh to
respect theirs and they'll do their best
to respect ours so that it's the least
amount of danger, effort and complexity
to make things portable between those
two agencies or between and the rest of
the government.
All right, that's it. We're three
minutes past. It's been a while since
we've had one of those. I really
appreciate all the questions. I I'm
sorry this is so many uh for us to keep
up with. Come back next week for the 20x
community update. Maybe you'll have an
opportunity to answer it. Ask some of
these questions again and we can move on
in through. Otherwise, we will see you
all on the other side and on the
interwebs soon. Cheers everyone. Thank you.
انقر على أي نص أو طابع زمني للانتقال إلى تلك اللحظة في الفيديو
مشاركة:
معظم النصوص تصبح جاهزة في أقل من 5 ثوانٍ
نسخ بنقرة واحدة125+ لغةالبحث في المحتوىالانتقال إلى الطوابع الزمنية
الصق رابط YouTube
أدخل رابط أي فيديو YouTube للحصول على نصه الكامل
نموذج استخراج النص
معظم النصوص تصبح جاهزة في أقل من 5 ثوانٍ
احصل على إضافة Chrome
احصل على النصوص فوراً دون مغادرة YouTube. ثبّت إضافة Chrome للوصول بنقرة واحدة إلى نص أي فيديو مباشرةً من صفحة المشاهدة.
