Security and Wasted Time

Security is necessary, I get that.

Security is a pain in the butt, I get that.

Security enforcers are very black and white, I don't get that.

We have a group of security enforcers who scans the local network with scanning software. The scanning software hacks up a report. The security enforcers then send the report to those responsible for a particular site and tell those people to cram it immediately into their schedule.

I didn't tell them, but I really wanted to cram it somewhere else ... in the schedule ... uh, yeah.

I had this opinion because the whole process is very disruptive and security enforcers are not reasonable in terms of schedule. Also, I believe the process is flawed and way to black and white.

Any item identified as "high" needs IMMEDIATE attention. Regardless of the fact that it might have been in production for 5 years on a low-traffic site which uses a protected account to expose data that by its very nature is public information.

It needs IMMEDIATE attention. Not tomorrow. Not weeks from now. IMMEDIATE.

Oh, and those other one hundred issues on the same report which are "medium" and below, they never have to be fixed, ever.

I have another problem. I have to fix a page which will probably be retired in a few months. Luckily enough, we don't have anything more important to do than throw today's effort down the drain tomorrow.

Comments

Post a Comment

Popular posts from this blog

Integrated Windows Authentication with Chrome and Firefox

Image
A few days ago, the Powers That Be at my institution rolled out a change to our web authentication scheme. Previously, we were using a proprietary system that somehow played nice with Active Directory. The changed made Active Directory Federation Services play nice with our proprietary system - making ADFS do the real work. Now, we live in the world of Integrated Windows Authentication. I'm all for that, mainly because the proprietary system was a PITA in a lot of cases. This new change makes a lot of thing easier. Plus, now logging onto your workstation logs you into our webapps! Well, not for me. I use a Chrome and Firefox. Well, not yet anyway .... It works great for Safari users on a Mac. However, I use Chrome mostly and Firefox for development testing.  How on earth do I tell Chrome what servers are okay to do Microsoft Integrated Login with? I guessed there was a way to configure Chrome and Firefox to do this, and it turns out there is! However...
Read more

Planned System Downtime

I have some thoughts on planned downtime. Ultimately it boils down to this: is the planned downtime caused by urgent, impending, and guaranteed doom? If yes, then by all means have the downtime whenever you can. If not, affected as few customers as possible, by the numbers. Planned system downtime should minimize impact to system usage - period. By "System Usage" I mean real customers using the system. I recently had a discussion with the systems group about a necessary outage on a system I support. Something important, but not urgent had the possibility to cause downtime on the system. However, if something went wrong and we had to restart a server, the server might not come up. This was deemed as needing pretty serious attention (which I agreed with). They found a fix and wanted to put it into production, as an emergency, planned downtime. We had a downtime window coming up, but this should probably happen before the window. They suggested an evening. Google Anal...
Read more

Error Handling

Image
I found this actual error message today while working with a vendor application: Okay, it wasn't that exact error message. And that's my code. BUT, the first part is verbatim. This is a server-side, vendor-provided, and above all, released product. This is not a beta; we paid someone to give us that error message. What am I supposed to do with that message. My code called your code and it told me "Unable to get resources." Guess I'll just take a nap till those resources can be gotten. Over the years I have seen both vendor applications and custom code where programmers are throwing away valuable information by not properly sending errors up the stack.   You should always, always, ALWAYS send your errors up the stack! * The error above could easily have been something like this: See, now I know something! This is a java.lang.NullPointerException exception in the file MeaningfulError.java - on line 11. That's an informativ...
Read more