Host Security: Pop Ups and Patch Management

Table of Contents

Pop-ups ...... 2

Pop-up Blockers -1 ...... 3

Pop-up Blockers -2 ...... 5

Patch Management ...... 7

Application Patch Management ...... 12

Patch Management ...... 14

Approved Application List ...... 15

Hardware Security ...... 17

Notices ...... 18

Page 1 of 18 Pop-ups

Pop-ups

Pop-ups (and popunders) refer to a class of images which appear on a user’s screen without the user performing any action to deliberately invoke their appearance. • Pop-ups are not directly an attack on a system, though large amounts of pop-ups effectively become a ‘denial of service’ attack on the user. • Not all pop-ups are bad. Web e-mail reply windows or spell- checklers, for instance, are often generated as pop-ups after a user request. • A number of tools can launch pop-ups, including Java and Active-X scripts, Adobe Flash, and Dynamic HTML.

**053 Next thing that we want to protect against is pop-ups. Now I have told you about I use something called Firebox as my browser. Google Chrome has got some of the similar or same things. You can turn on disable and enable pop-ups. There are certain sites that I go to that I need that pop-up. That pop-up is an authentication mechanism that's separate from this environment right here and it's valid. So it's not really an attack on the system. When it's an attack on the system is when we go to some site and that site has a whole bunch of advertisers on it and those advertisers want to get in your face and they pop up a separate

Page 2 of 18 window that says "Act now, buy this thing." And they can do it with all sorts of different techniques out there, Java, Active-X, Adobe Flash, Dynamic HTML, it does not matter. They can do it a whole bunch of different ways. Pop-ups and popunders is also the other term because it goes underneath. So when you close your browser there's the advertising that they got from you. Pop-ups are a problem and so we can filter and say we won't allow any pop-ups but then that kind of breaks some of the sites that we go to.

Pop-up Blockers -1

Usually activated in web browser settings • Pop-up blockers can be set to block all pop-ups, but can also be tuned to ‘trust’ designated sites (such as your web e-mail account, etc.). • Web browsers can also prompt to allow pop-ups on a per-session basis, permitting pop-ups only during a particular visit to a web site. • Third-party ‘plug-ins’ can also install pop-up blockers. This can create confusion when a user wants to allow a pop-up and it is being blocked by multiple pop-up blockers.

**054 So this is a setting in most of

Page 3 of 18 your browsers to disable that. You can disable that universally. You can disable that for certain sites. You can white list certain sites that okay they can always give me pop-ups this is one for me. I have an Adobe Connect account that checks for that and when it actually tries to instantiate my Adobe Connect, it says "Hey, you want to white list this?" and I always say yes. So we can be granular about our protection mechanisms for pop- ups.

But that means that if we're doing it for somebody else, we need to tell them that we're blocking pop-ups. We need to make that a part of the policy and end users aren't going to remember that so we have to continually train them on that. That goes into our awareness for the end users to say pop-ups are bad. We stop them but every once in a while you may need them and if we are producing an application internally for our users, we have to enable pop-ups for our application. If we are producing an application for other users out there on the in the rest of the planet, we have to say "When you buy this service, you got to enable pop-ups for our site so make sure that you do that now." And it's even better, this is what I do for my users is I actually show them if you have Chrome click here and you can see how you can do it. If you have Safari, do this. If you have Opera, do that. If you have IE do this. And walk them through the steps of enabling pop-ups for our one sight.

Page 4 of 18 Unfortunately and fortunately same, it could be that they are not allowed to do that. That their configuration has been locked down by you as the security administrator so that they don't have the permission to do that. That happens quite often, even with security people because we all have to follow the same policy. So what do you do? Well you don't do pop-ups. Well I need pop-ups for this authentication mechanism to make it more secure so now we are kind of fighting back and forth from an availability standpoint.

Pop-up Blockers -2

Not 100% effective, and some pop-ups will still appear even with pop-up blockers enabled

• Excessive uncontrolled pop-up activity is usually the result of some other system compromise, and not merely the failure of a pop-up blocker. • Not all pop-ups come from web browsers. A popular attack against Windows machines was to send pop-ups via the Windows messenger service (which led to the service being disabled by default).

**055 Pop-up blockers are not 100

Page 5 of 18 percent effective. I want to figure out which ones are-- I want to find out which ones can always get through because that's the mechanism that I want to use so that I don't have to train you on how to turn off pop-up blocker and also have to fight your configuration. But that's not a topic for here but you realize the problem that we're running into or that I'm running into. It's not 100 percent effective but we'll take what we can get. Now there are tools and plug-ins for different browsers out there that will allow you to tune the pop-ups back and forth. And I really like those tools.

Page 6 of 18 Patch Management

Patch Management

Anti-virus deals with known threats as they enter your environment over the wire, but not errors and vulnerabilities that exist in software, these system and software vulnerabilities must be patched. Patch management should follow same process as change control procedures, including approval testing and confirmation that the changes were successful. Patch management software • Centralized repository • Means to view and test patches before deployment • Control the required versions that are in the environment

**056 Patch management is upgrading versions of software correctly to a new version that does not have the old version's vulnerability.

But then when we move forward in time, eventually evil doers will find a vulnerability in this version of the software and the people who write the software will have to create a new version of this that will move forward to in time. And what we're doing is we are going from one known good to a bad to the next known good and then it becomes bad to the next known good. We are moving from one known good to another.

Page 7 of 18 I believe that patch management should not be done by the vendor of the application because they are not going to consider your environment. I believe it should be done by you in a centralized management way for all the computers under your control. That means that we're going to have to have some sort of agent-based system.

Now there are agentless-based systems that are out there for patch management. The problem with agentless systems is they don't respect the end users' need to do work. If you say "We're going to push out a patch at midnight tonight because nobody is there and an end user is working on their machine because they've got to get done and they have a deadline that is midnight," you're going to stop them in the middle of the work. With an agent-based system it queries the local machine and it says "Hey, look, we're going to roll out some patches. Can you delay this thing?" And you say "Dan, my operating system does that for me already. It allows, it pops up and says can I do this later? Can you try this later? What can you do as an end user when it says try later? You keep on hitting that try later button and you just get it out of your way.

Whereas when we do this in an enterprise way what we say is okay, when is an appropriate time for you, your group or your organizational unit for us to roll out this patch? And if you want to keep on delaying that

Page 8 of 18 patch because you have a critical business application that's going on, you hit the delay button and it reports back to us that they've done a delay. You then take that delay information, you aggregate it for all the users and say "We've patched everybody except for this one department right here. They are asking for an exception to not be patched for this moment in time." For this application, this operating system, whatever it is, this custom DLL This is software deployment and this is forced software deployment.

For the good of the security of all because if this machine, one machine where they keep on delaying like that actually gets attacked, then that becomes a launching point for the attacker to attack all the other machines in our environment. It's not that your machine is a problem. I mean that would be sad and you couldn't work. It's that your machine now becomes an attacker for all the rest of the attackers out there. What we also need to do with patch management is respect the fact that business needs to get done even with an unpatched machine so we should start thinking about our next layer of defense, our defense in depth and saying "Okay, can we protect that machine using some sort of intrusion detection system, some sort of filtering or stopping it from going to the sites where this malware exists?" We put up those defenses out there so that they can keep on running, finish their business process, get

Page 9 of 18 through the exception and say "Okay, now I'm ready to be patched."

But the other big problem with the interaction between the user and us for doing business. The other part is that our business process is different than everybody else's business process and our applications that we install on our machine are unique to us. And the vendor does not pay attention to that uniqueness. They test for and they should, they test for 99 percent of all people that are out there that have this configuration. They can't test for that one percent that we are.

Now we're not this one percent now, but sometime in the future, we're going to fall into that category of that one percent and in that moment in time we're going to kill off the operation or the computer at that point. Vendors are getting better at this but they all want to have their own patch management way to produce this and that does not give us a clear way to do change control. Because patch management really underneath of it at all is nothing more than software updates and software updates really are a change management process that relates back to our risk management process. We want to have orderly change so that we move from one known good to the next known good and we want to know what the potential effects are on our environment, so what we do is in change management we apply for the change and request that change

Page 10 of 18 and then we go and test and see that this will work on all of our environment before we actually roll it out.

If the vendor is allowed to go ahead and crank this stuff out well guess what, they're just going to keep on applying it the machines and they're going to take it. They're going to put it on the machine and if it breaks they don't care. It's not that they don't care. It's that they can't test for every single condition in the market. We as change management experts for our organization know what's appropriate and what's inappropriate for our organization, what will break things and won't because we do the testing.

Change management is a part of risk management. Because at the very end of change management, what we do is we go to the people in our organization that are making the business decision and we say that "This is a risky process, this is not a risky process, it's more risky to patch than it is to not patch and we recommend patching at this point and it should take us this long to do it." And business says "We realize that you want a patch right now. We've got this important business process going on that we're closing out the books for the month. No, we're not going to let you do that." Or "You can do that in three days. We accept the risk to operate in the environment unpatched." That's their job.

Page 11 of 18 Application Patch Management

Application Patch Management

Operating System patches are critical, however, many people forget that third party applications are where many of today’s attack vectors target. Applications need patches just like Operating Systems do. • An application exploit can result in compromises. • Most vendors provide patches on a regular basis. Client Side Attacks • Many attacks today target client side applications. • Patching historically is not done well for applications.

**057 When we talk about application patch management as opposed to operating system patch management it's the same thing all over again. But now it's an application. And is that application present on our machine? And that's kind of the big question. So that means that we have to have an accurate inventory of all of our computers and all the software on our computers and if we were trying to do that by hand, we'd be in hell and that's my other thing that I say in patch management is it must have an agent, and it must be automated for all of our operating systems so that means we need to be cross-

Page 12 of 18 platform capable, and we also need to be able to do this for all the applications that are out there.

That means that we're eventually going to have to learn how to write a software deployment package for all of our machines in our environment whether it's a Unix machine or whether it's a Macintosh or whether it's a Windows machine. We need to be able to deploy software successfully. Not program but just deploy successfully.

Because application patch management and operating system patch management is nothing more than software deployment.

Page 13 of 18 Patch Management

Patch Management

**056 And when we are in software deployment if we follow the SDLC one of the major steps is testing.

Page 14 of 18 Approved Application List

Approved Application List

The amount of applications you have can get out of control very quickly, especially when you consider different versions. • Baseline list of approved applications • Process to acquire and test new software • Limit the versions that exist in the environment Controlling the number of potentially vulnerable applications will enhance the ability to mitigate potential compromises . Whitelisting – Approved list of application Blacklisting – Block unapproved applications

**058 Now you can be even more specific about this when it comes to applications and you can say "This is the software that we will allow. And here's the list that you can use." Well what about this? No. What about that? No. What about this? Go ask your manager for approval on that. "I want to run a Doom server because I'm going to do gaming over the weekend. We're going to do a gaming marathon." "Is that a business attribute?" "No but I want to do it." "Ask your manager to sign off on that particular application and then I'll load your Doom server for you." You are not allowed to install

Page 15 of 18 software yourself and we take that away from you.

So the approved application list requires two things, three actually. It requires us to do all software deployment. It also requires us to have an exceptions process in place that is fast enough to deal with the business uses. And it also requires us to do a risk assessment of a level. If you want to install this on your local workstation, that doesn't have nearly as much risk as if you want to install it on the main file server. And so we need to do the risk assessment process along with this. Approved application list makes it much cleaner to do change control because now when somebody wants something that's not on the approved list it goes into the change control process and comes out the other end that says "This is a reasonable business risk to take for this application and we know what all the risks are of installing it on that workstation or that server.

It may even be that the approved application list starts to extend out to software as a service." And you may say "No, we won't purchase that kind of software because it puts us at risk because we have to export data to it." Have you ever seen these applications now that will say "Hey, we see that you come here all the time and you have to keep on adding in all these people yourself? Why don't you just export your contact list to us and we'll be glad to do it for you so that you don't even have to worry about it. And we can put a

Page 16 of 18 connector in there that will every time you create a new contact it will add it to the list here." "Oh, thank you for being so convenient for me. Gosh that's such a wonderful thing. I think what I'm going to do is I'm going to exfiltrate all the data and all the people that sell to my company to you." Hmm, probably not a good thing.

Hardware Security

Cable Locks • Prevents people from stealing devices at the desk • Almost every laptop has the built-in slot • Desktop locks can prevent access to the hard drives Safe • Consider using a safe for locking up important information • Forensic data (original hard drives) should be stored in a safe Locking Cabinets • It is also a good idea to lock up cabinets • Often used to store backup media, supplies, and documentation

**059 Hardware security. Now we talked about this in the physical area. Cable locks, safes, and locking cabinets, those are all basic business principles that have been learned very well. By who? Not by regular

Page 17 of 18 corporations. Now if you are a regular corporation and you don't know what to do, the best place to go is to your local branch manager and ask them what they do for physical security. If you have a relationship with them, they'll say "Well we've got locking file cabinets here. We've got safes over there." They got lots of safes. And they've got cable locks for all the computer equipment or it's basically it's tied to the table in a lot of cases.

Notices

© 2015 Carnegie Mellon University This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study. Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected]. This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide. Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding. THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT). CERT ® is a registered mark owned by Carnegie Mellon University.

Page 18 of 18