As a security professional, I talk to a lot of people about common security attacks and countermeasures. I’m not always certain the people I’m talking to know what these things mean. I am almost certain they aren’t willing to ask.
I know it’s more complicated than it was when I took my Security+ exam a decade ago. The stakes are much higher now. The attacks I had to identify caused inconvenience, but someone conducting a successful smurf attack on your printer won’t get you in the headlines. Today’s attacks will.
Vulnerability management and patch management are close relatives. In most companies, think of them as siblings who hate each other. That’s usually how it plays out. It doesn’t always have to be that way, but it takes some thought and strategy from both sides. Here are some ideas for patch management strategy.
Besides work experience, I probably get more questions about CISSP continuing education than anything else CISSP-related. Fortunately, keeping your CISSP can be a lot cheaper and easier than getting it in the first place was.
CISSP continuing education is measured in CPEs. You get one CPE per hour of “study.” Study is a pretty loose term. If you’re learning about security, you can probably find a way to make it count. You need to get 40 CPEs per year.
I met with a client earlier this week who asked me to go over their vulnerability scans for a bit of a sanity check. He asked some important questions, but one in particular seems worth sharing. What can we do with Java? Can we solve the Java problem?
Last week at work, I noticed some odd events in an event log, and when I investigated them, I found they were part of a failed ransomware attack. This got me thinking about how to prevent ransomware at home.
Ransomware, if you aren’t familiar, is an attack that encrypts your data and demands a ransom, usually around $300, in bitcoins, and you get a short deadline until it destroys your files. More often than not, paying the ransom is the only way to get the files back, so it’s much better to prevent it.
I had a Java app pointing at a Forcepoint (formerly known as Websense) proxy server. The proxy server wasn’t working, and the app was giving me a 407 error.
We had Websense set to require NTLM authorization, but it turns out Java won’t do NTLM, so the Java traffic wasn’t even showing up in the monitor.
My workaround was to have users open a browser, then go to any web page immediately before opening the app. By letting the browser authenticate for it, the Java app worked thanks to Websense having the credentials cached.
If you want, you can launch the applet with a batch file that uses IEcapt to hit any web page, then starts the applet.
I’ve been asked a few times now for my recommended DD-WRT settings, or at least my good-enough settings. I think that’s a great idea, so I’ll walk through how I configure a DD-WRT router. Follow these steps and I can almost guarantee you’ll have the most secure network on your block.
For the purposes of this tutorial, I am going to assume you are configuring DD-WRT as your primary router.
One of the best things you can do to improve your security in a corporate environment is to limit the use of Java, or whitelist Java. Undoubtedly there will be one or more legacy web applications your company uses that require Java, and it’s almost inevitable that at least two of them will be certified for one and only one version of the JRE, and it won’t be the same one.
Believe it or not there’s a solution to the problem of conflicting JREs, but it took me years to find it, because I had no idea that Oracle called it “Deployment Rule Set.” The secret’s out now. If you run Java, and you want security, you needDeployment Rule Set.
I found a mention of a tool called Unchecky as a minor point in a story about something else entirely. Unchecky helps to solve the problem with downloaded programs including a bunch of extra junk you don’t want.
I won’t be running it myself. But the next time I fix a computer, I’ll probably install it on that one.