JANET MINER: Hello.

I'm Janet Miner, director of the IRS Office of Safeguards.

We are responsible for ensuring the protection of federal tax information, or FTI as you will hear it referred to, which the IRS provides to local, state, and federal agencies.

While the IRS has the oversight role in protecting FTI, our agency partners receiving the data play the most important role.

Each of the more than 300 agencies who receive FTI from the IRS must build effective security controls into their processes, procedures, and systems to ensure that the confidentiality of tax information is continuously protected from the time of planning for the receipt of FTI throughout its life cycle until the FTI is destroyed or returned to the IRS.

You and I, your agency and the IRS, are in this together.

We must be successful in our efforts to guard the security of FTI.

Neither of us can afford the fallout that comes from unauthorized disclosure of federal tax information.

The American public expects two things from both of us - first, that we protect the right to the privacy and confidentiality of their tax information and, secondly, that we work together proactively to be as efficient as possible.

When we are exchanging their sensitive financial information, we must ensure that their personal data is not inappropriately shared with others.

As part of working in tandem to protect FTI, we routinely discuss with agencies the security requirements to include in new processes, procedures, or policies that they may be building.

Many times the new processes or procedures are needed due to changes in the data an agency may be receiving or because system improvements have afforded an agency the opportunity to change the way they do business.

Anything Safeguards can do on the front end to partner with an agency designing and building a new application processing FTI is in all of our best interests.

Many agencies are planning to replace their old Legacy systems in the coming years.

So, we hope that you find the information in this video useful.

This information is designed to assist local, state, and federal agencies in designing and building a new application containing FTI.

It will cover key elements an agency should include for data protection.

Before we move into the substance of our discussion, let me just say thank you for everything you do to protect the confidentiality of federal tax information.

I truly appreciate it.

SHAWN BUCKNER: Hi.

I'm Shawn Buckner, and I'll be moderating our discussion today.

I'm the Acting Chief, Program Operations, in the IRS Office of Safeguards.

Joining me on the panel today are Sammi Shultz, the project manager for our office, and Jonathan Isner, the project lead from Booz Allen Hamilton, our contractor for computer security support.

Today we want to talk about building Safeguard requirements into the design and implementation of new applications which will contain federal tax information.

Okay.

Let's get started.

Before we get too far, Sammi, can you describe for us what is federal tax information?

SAMMI SHULTZ: Sure.

Return and return information that we provide to an agency is federal tax information.

The way to tell whether it's federal tax information or not is whether the IRS is the source.

Now, there's sometimes that we're the source, but we're not actually the delivery mechanism that the data comes through.

For instance, refund-offset information is provided to agencies from the Financial Management Service, a sister agency within Treasury, or sometimes it comes from Social Security directly instead of from us even though it's our data.

So, it comes down to, was the IRS the source of the data?

And if we were, then it's federal tax information that has to be protected.

And federal tax information never loses its identification or integrity as federal tax information.

From receipt to destruction, it remains federal tax information.

SHAWN BUCKNER: So, there's no length of time that would make something no longer federal tax information?

SAMMI SHULTZ: No, sir.

It comes back to source.

If it came from us, then it's federal tax information.

SHAWN BUCKNER: Jonathan, I've heard a lot about the system-development life cycle.

Please tell me about what it is and how it works.

JONATHAN ISNER: Sure.

The system-development life cycle is really a process that guides system-development projects from the inception of the business need all the way through till when that system reaches its end of life and needs to be disposed of.

In order to be most cost-effective in building security, the security elements really need to be built in at the initiation of the system life cycle so that you're able to identify risk and address it as you progress through those phases of the system-development life cycle, hopefully being able to mitigate that risk at a lower cost than what we typically see as it being added on towards the end of the life cycle.

SAMMI SHULTZ: We get a lot of inquiries from agencies who are now trying to retrofit security onto an existing system.

So, what you're saying is they need to build it in -from the beginning.

JONATHAN ISNER: Yeah.

Throughout every phase of the life cycle, there should be defined security tasks that need to be performed before you actually move on to the next phase.

So, by doing that, you're able to build requirements in early into the design and make sure that the security features are functioning properly and doing what they're supposed to be doing before you go and try to deploy the system.

SHAWN BUCKNER: So, Jonathan, any agency that's looking to build a new application needs to consult their system security policy?

JONATHAN ISNER: Yeah, that's correct.

The security policy is really the foundation or the cornerstone of how security should be designed and implemented in any system.

The policy should lay out the goals for confidentiality, integrity, availability, and generally drive the security requirements that will be built into the system.

Now, Publication 1075 is that security policy for any system that's going to receive, store, process, or transmit FTI.

SHAWN BUCKNER: Is there anything that application developers need to know that is addressed within Publication 1075?

JONATHAN ISNER: Sure.

I mean, the application developers or system integrators, depending on the type of project, should really be educated on Publication 1075 and be very familiar with the requirements therein, as well as just general security engineering principals or secure coding principals.

SAMMI SHULTZ: And if the system engineers or the application developers are going to want to do any kind of testing, then they're going to need to notify the IRS because they have to have our approval to use federal tax information in a preproduction environment.

Because usually don't we see, Jonathan, that they're really not as secure as a production environment?

JONATHAN ISNER: Yeah, typically the preproduction environment, because of the nature of how it's used for testing, is not secured like a production environment is.

So, we have this process in place to allow the IRS to learn some information about how the agency plans to use that federal tax information in their preproduction environment, whether it's for testing, development activities, staging, that kind of thing.

It allows us to understand a little bit how they're going to use it and what controls are going to be in place so we have an assurance level that the data is protected while it's in that environment.

SAMMI SHULTZ: Even what they're going to do when they're done.

JONATHAN ISNER: Correct.

SHAWN BUCKNER: Jonathan, are there any specific requirements that are in place or need to be in place as it relates to identification and authentication?

JONATHAN ISNER: Yes, there are.

Any system that's going to receive, store, process, or transmit FTI must uniquely identify every user.

And then there's minimum password requirements that have to be met, as well - things like a minimum of eight characters for a password, complex passwords using special characters, alpha-numeric characters, that kind of thing.

Password aging - ensuring that passwords expire after a certain time period and users are required to change them frequently.

Additionally, if there's any remote access to a system with federal tax information - let's say VPN access, an employee working at home - that remote connection needs to have two-factor authentication, which is a stronger authentication mechanism than your normal password.

SAMMI SHULTZ: We get asked all the time, "What constitutes two-factor authentication?"  Can you explain it a little bit?

JONATHAN ISNER: Sure.

Like I said, it's just a stronger way to verify the identity of the user - that they are who they say they are.

So, it's using a combination of two out of three possible factors - something you have, you know, like a smart-card like your HSPD-12 card or a token, a one-time password token, something you know, which is typically your password or a pin number or something like that, and then the third could be something you are, a biometric like your fingerprint.

SHAWN BUCKNER: Sammi, can you talk about "need to know" as it relates to federal tax information?

SAMMI SHULTZ: Certainly.

"Need to know" comes down to you should only have access to federal tax information if you have a need to know because of what you do for a living.

So, when we give information to an agency and they're looking to see who needs to have access to it, it should be based on those employees' positions - what they actually do, what they need to do their job.

The other piece of "need to know" is what does the statute say that you're allowed to use it for?

Because if the statute says - the statute under which we give information - says that they can only use for tax administration, for instance, then using the federal tax information for anything else violates that premise.

So, it's, first, is it being used for what the statute intended it to be used for, number one, and then, number two, who has a need to know?

We'll see sometimes where different case workers or different groups of employees within an agency have a different need for different information based on what they do for a living.

So, this group of employees may need five different data elements, and this group over here needs a different set of data elements.

So, setting those up as "need to know" only within those particular data elements is what you need to do for systems development.

This is, again, a place that we need to have focus by both the I.T.

staff and by the program staff to work together to identify what those groups are and what their actual need for data is.

It should be kept to a minimum.

The employee needs to be given only the FTI they need to do their job.

And in an application-development sense, then building role-based applications so that the access controls that Jonathan may have based on what he does may be different than the access controls that you would do because you do a different kind of position allows, then, that the employees are gaining access only to the different pieces of federal tax information that they really need to do their job.

SHAWN BUCKNER: Sammi, how do you actually know - how does a user know that they're even looking at federal tax information?

SAMMI SHULTZ: Hopefully they've been trained by their agency.

That should be the first part.

When Jonathan talked earlier about access and about identification, hopefully part of that, as well, is understanding how the data flows and understanding that this is the data that I'm looking at.

There also is a warning banner that should be in place.

Now, the IRS prefers that the warning banner be as close to the application that actually contains federal tax information as possible, but somewhere between the time that the employee logs on to when they access federal tax information, there needs to be a warning banner.

And that warning banner needs to cover four things.

It needs to say that they're about ready to access U.S.

government information, that they're subject to auditing or oversight for being in the information, that unauthorized access is prohibited, and that there are sanctions associated with that unauthorized access.

Now, we don't really care, to a large extent, what their warning banner says as long as it has those four components.

Some agency applications, they can put the warning banner right as you go in.

Others, the older Legacy systems, it may be much closer to the front, where the employee signs on for the first time that day they actually see it.

SHAWN BUCKNER: Is there a place where an agency can go if they don't have a warning that's sufficient that they can get information to add to or create their own warning?

SAMMI SHULTZ: Sure.

There's a couple of places, actually.

An agency could go out on IRS.gov and go to the Safeguard program's Website.

And out on the Website there is a copy of warning banners.

There's three different ones that they could pull directly off the Website.

The other thing they could do is look at Exhibit 13 in the 1075.

It also has three different versions of the warning banner.

Now, those warning banners start fairly big, and they go down to smaller text.

They were deliberately done that way so that if there are space limitations or character limitations that an agency would have, they would be able to use the one that works best for them.

But one thing, Jonathan, that we also need to probably mention is not only does that warning banner need to be where the end users are coming in, but it needs to be where the system administrators and those back-end folks are, as well.

JONATHAN ISNER: We often focus so much on the end-user access that we forget about the database administrator or the server-operating-system administrator.

You know, they have access to that data, as well, because of their job function.

So they need that same warning banner to be in place on their log-ins.

SHAWN BUCKNER: Jonathan, you're saying there's no distinction in terms of the application of the statutory rules between the end user and the front-end user?

JONATHAN ISNER: Right.

Even though they are performing different job functions, per se, they all have access to federal tax information, and they have that need to know to access the federal tax information.

So, they need that warning banner.

SAMMI SHULTZ: In fact, the folks on the back end generally have access to more data because a systems administrator can see potentially all the data that they have that's federal tax information.

So, that's why it's so important that we make sure that both the users on the front end and then the folks that are on the back end, the system administrators, database administrators, all have a warning when they come in.

SHAWN BUCKNER: And that makes that training that you mentioned paramount.

SAMMI SHULTZ: Exactly.

SHAWN BUCKNER: Jonathan, it seems like labeling and auditing go hand in hand.

Can you explain the auditing side?

JONATHAN ISNER: Sure.

So, auditing is a detective control that's used to really identify potential unauthorized access to FTI or security anomalies that are occurring on the system.

Publication 1075 requires auditing of any access, modification, deletion, or update to federal tax information.

So, in order to properly identify those transactions that contain federal tax information that need to be auditing, that audit trail needs to key off that label of federal tax information in order to be, you know, properly captured.

Now, it's not just enough to capture audit logs, you know, volumes of disc with a bunch of audit records on it.

You know, it doesn't do us a whole lot of good unless we're actually looking at it, reviewing it, trending, seeing, you know, what might be going on in the system, are there security anomalies, are there things that we need to investigate.

SAMMI SHULTZ: Nobody can look at hundreds or thousands of lines of an audit record and look to say, you know, "Those five look suspicious."  It's just not possible.

One of the things that Safeguard's looking to go to sometime in the next probably three to five years is what we're calling proactive auditing.

And it's basically taking your audit logs and running mathematical algorithms against it to be able to identify those trends, to be able to see if you have anomalies or to see if you have an employee doing something they shouldn't be because they're looking up somebody whose address is three doors down from theirs or they're looking up somebody that has the same last name - those types of things.

So, it is a requirement that we're starting to look at.

We've been working with a stakeholder group that we have to try to develop what would be the right thing to do to go down that path.

It will likely be three to five years before we get there.

So, folks that are building new systems now - labeling becomes even more critical because if it's not labeled correctly, then you're probably not generating the right audit logs.

And if you're not generating the right audit logs, then when you get to proactive auditing, you're going to be trending against data that may be a little quirky, and it'll be much more difficult.

So, all of this ties together.

And it's all about protecting the data that we have and making sure that nobody's doing anything with it they shouldn't.

And, frankly, most of the agencies need to do this - but most of them do - with their own data, not just our data.

And so it's all about - in a world today when we have identity theft and we have privacy concerns - making sure that our folks are doing the right thing with our data, as well as with the agency's data.

SHAWN BUCKNER: Building upon the issue of auditing, is there a record retention that's required for keeping audit logs so you could potentially engage in this analysis and review?

JONATHAN ISNER: Yeah.

The Publication 1075 requires that agencies retain their audit logs for six years to support after-the-fact investigations.

The other point I wanted to make, too, was back to the concept we talked about earlier about needing auditing at multiple layers.

So, it's not enough just to audit at the application layer, for example.

You really want to audit at all those layers we talked about - at the application, at the database, and at the operating-system level.

SHAWN BUCKNER: Why is that important?

JONATHAN ISNER: Well, back to what we talked about, you have different folks performing different roles.

The database administrator could potentially query that database directly through the database-management system without going through the front-end application.

So, you want to make sure you're capturing a record of all the possible access points to the federal tax information.

SAMMI SHULTZ: That's why the auditing requirement talks about looking for modifications, deletions, additions for each unique user, because we need to see, as Jonathan said, both the front end and the back end in order to see if there's some type of trend or there's some type of anomaly that's going on.

SHAWN BUCKNER: Jonathan, let's continue with this notion of security but from a wider lens.

Coming from the outside, is encryption important in security?

JONATHAN ISNER: Absolutely.

Encryption is very important.

Publication 1075 actually requires that all FTI in transit, whether that's within your local area network or if you're going to send it somewhere beyond your local network - let's say maybe a remote connection or over the wide area network - be encrypted, as well.

The importance of encryption is just that it prevents people from eavesdropping on that connection and stealing that data, per se, while it's transmitted over the wire.

Now, this can be accomplished in a couple different ways depending on how you're making those transmissions.

At the application layer, let's say an agency wants to use FTP to move some data across the wire.

Well, we want them to use a secured FTP protocol so that we know that that data's encrypted while it's being transmitted.

Let's say they're using the Web to transmit traffic.

We want them to use SSL or transport layer security, TLS, to encrypt that data at the transport layer.

SHAWN BUCKNER: We hear a lot in the news about computer viruses.

Are there specific things that agencies can do to protect themselves against viruses?

JONATHAN ISNER: Yeah.

Agencies should employ layered security, or defense in depth, as it's referred to.

What this really means is just employing a segmented network that uses boundary-protection mechanisms at each network segment in order to properly control the flow of FTI from the point when it's received into the network perimeter all the way till it hits that segment where the FTI is present.

So, you want to have devices like firewalls, routers at the edge of those network segments inspecting that traffic inbound and outbound to make sure that only the legitimate traffic that's necessary for the FTI system is able to get to that system.

SAMMI SHULTZ: And intrusion-alert-type software -is also handy, isn't it?

JONATHAN ISNER: Yeah.

You definitely want to have intrusion-detection or intrusion-prevention systems inspecting that traffic, monitoring it, looking for viruses and things of that nature, and alerting people to take action when an anomaly is alerted.

SAMMI SHULTZ: One of the things that the August 2010 version of the 1075 did was put into play requirements if you're going to have a Website that you have customers that can come in on, because obviously they're going to want to come in and get their information.

But we need you to have a tiered architecture if you're going to do that so the federal tax information isn't where anybody could get to it.

And you have to have strong passwords or a strong type of authentication so that if you're the customer coming in that we know that you are you.

And so that was one of the improvements that came into the last version of the 1075.

JONATHAN ISNER: Yeah, and you definitely never want to store any federal tax information on any server that's directly accessible from the Web.

So, your Web server, for example - you don't want to store data on there.

And that's the tiered architecture that Sammi's talking about about breaking it up so that there are layers in between that end user who may be out on the Internet and where the data is actually stored.

SHAWN BUCKNER: When agencies need specific configuration settings, where do they go to find it?

JONATHAN ISNER: Well, agencies are required to put in place mandatory configuration settings for systems that receive, store, process, or transmit FTI for the security settings on those systems.

Now, the Publication 1075 itself doesn't go into the specific details of every platform technology and the specific configuration settings for that technology, but we have supplemented the publication with what we call the Safeguard Computer Security Evaluation Matrices, or SCSEMs that we refer to them as.

These are actually the testing vehicles that our team will use to conduct the on-site Safeguard reviews.

So, they're an excellent tool for the agency to use to harden their systems even in preparation for our review team coming out and conducting the review.

SAMMI SHULTZ: Or even to go in and look - as far as continuous monitoring - to go in once a year and double-check, because we do update them sometimes if we've added requirements or if we've tweaked a bit.

And so an agency could use those on an annual basis simply for continuous monitoring.

They're out on the IRS.gov site.

They're on the bottom of the main landing page.

And we try to be very transparent and put everything up there that anyone could possibly need to be able to go in and use.

So, not only does it have the configuration settings in it, but they're great for hardening the system and they're great for being able to do continuous monitoring.

JONATHAN ISNER: Yeah.

I think we have over 20 different SCSEMs now at this point, all sorts of operating-system platforms - Windows, UNIX, Linux, mainframe security software, network devices.

It pretty much covers the whole gamut.

SHAWN BUCKNER: And all those SCSEMs can be found on IRS.gov?

JONATHAN ISNER: Mm-hmm.

SHAWN BUCKNER: That's great.

Sammi, how does an agency seek assistance when they need help?

SAMMI SHULTZ: There's actually two ways I would recommend to agencies.

The first is to go check the IRS.gov Website, especially there's an area out there for guidance by technical topic, and see if someone else has asked the question.

Over the last several years, as different agencies have asked us different questions, we have taken answers and put up on the IRS.gov Website, figuring if one agency had the question, somebody else may, as well.

But many agencies have very specific needs.

They need to talk to us about their environment - and everybody has a unique environment - to be able to say, "We need to do," or, "We want to do 'X,' 'Y,' and 'Z,' and will this work against the requirements of the 1075?"  What we suggest is that they send in to the mailbox - the safeguardreports@IRS.gov mailbox - an e-mail that says, "We would like to talk to somebody on a conference call."  And we do a lot of those conference calls where we just sit and talk with the agency.

"Tell us what you're looking to do, what you're wanting to do.

"Let's talk about what the 1075 requirements are.

"Let's talk about the constraints "that are within your environment and figure out the how, if you will."  The 1075 will tell them the what.

It tells them what the requirements are, but much of the time the agency then needs to figure out the how given their own environment.

So, they just need to send an e-mail in to the mailbox.

We'll set up a conference call, and we'll sit and chat with them.

SHAWN BUCKNER: I think that's all the questions we had for today.

Thank you, Sammi, and thank you, Jonathan, for joining us today.

We've covered a lot of information today, and I hope it's been helpful.

We look forward to working with you in the future.

Please don't hesitate to send your questions to our mailbox at safeguardreports@IRS.gov.

Thank you for joining us this afternoon.

JANET MINER: Good security protocols are founded on the idea of continued vigilance such as completing disclosure-awareness training, conducting routine reviews of the agency's policies and processes, and reviewing information-technology systems to ensure access and password protocols are up to the appropriate standards.

I hope that you've found the video informative.

We look forward to working with you as you develop requirements for your new system or application.

If you need to discuss the Publication 1075 requirements, please do not hesitate to send an e-mail to our mailbox at safeguardreports@IRS.gov to request a conference call.

Again, thank you for your attention and for your efforts to protect the confidentiality of federal tax information.

Goodbye.