Comment Re:This isn't fixing SSL (Score 1) 379
By "fixing SSL" I meant "fixing OpenSSL". Duh!
By "fixing SSL" I meant "fixing OpenSSL". Duh!
The article doesn't make it completely clear that this doesn't have much to do with the fixing problems in OpenSSL.
Commits to the true OpenSSL source can be seen through the web interface at https://github.com/openssl/ope.... What the article is talking about is tidying up the version that is built in to OpenBSD. Not that that isn't worthwhile work, but it's unlikely to fix many hidden problems in OpenSSL itself, unless the OpenBSD devs find something and hand it back to the upstream.
Indeed. When we introduced our change management process I realised that I was informally doing this risk analysis anyway. The change management process and CAB just formalise it.
Risk analysis can be as simple as thinking "is this low impact" for a second and then deciding it is and continuing. Most of these types of changes are pre-approved by CAB and we just have to record the change. If we started creating outages from these types of changes then that pre-approval would probably be reviewed.
There are other times when that pre-approval is temporarily revoked when the organisation cannot tolerate the risk of any downtime caused by changes, but that only happens twice a year, and I get to put my feet up a bit and work on interesting hobby projects for a couple of weeks
It needn't difficult at all and it doesn't have to impact your ability to apply security patches. For example, patches from Microsoft released on the 8th April were applied to roughly 500 servers on the 11th. A couple of hundred of our servers applied the software remedy for heartbleed within hours of it being released, without any intervention from a human at all.
A change management process should take into account an organisations appetite for risk. For us, we're keen to apply security patches quickly, so they are pre-approved by our CAB.
I have to do this and it's no problem at all, although our change management process doesn't sound quite as onerous as yours (I suspect yours will adapt over time -- the CAB will soon get bored if they have to approve every single OS patch).
I have to do a risk analysis for each change that gets made to a system (not just patches). Sometimes this risk analysis is fairly informal, for example if the change is to add more RAM to a VM, it's very unlikely to have a significant adverse impact and is easily reversible, so low risk. Other times the risk analysis (and processes that come out of that) may take a long time and require significant co-ordination with other parts of the organisation I work in.
A good example is if we make a change to a service that impacts the look and feel of that service. It will require co-ordinating with our communications, helpdesk, training and documentation teams as well as other parts of the technical group I work in and the CAB really acts as a check to make sure all of that has happened properly.
There are still a few people in our organisation who see the CAB as a barrier to getting work done, but for me it is really a check to make sure we're delivering changes in a proper way.
I can recommend you take a look at The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. http://itrevolution.com/books/... - I had quite a few "this is where I work" moments whilst reading it
"I took the initiative on creating the internet".
Do you mean GBIC? I'm not aware of them using LEDs. For optical GBICs lasers are used (usually VCSELs - or they were when I last cared about the internal workings of fibre stuff, which was about 10 years ago ).
That's still proxying and not NAT. I would be stunned if ISPs started routinely proxying all HTTP traffic (and they don't stand a chance with HTTPS). The amount of processing resource required would be unfeasibly large.
X-Forwarded-For won't help with CG-NAT. Any XFF: address would be a fairly meaningless RFC6598 address, and that's assuming that the ISP is running a proxy as well as CG-NAT.
SHA-512 is a cryptographic hash function. Faster computation of hashes is exactly what you *don't* want.
Fifteen!? Luxury! From the UK you're looking at about 24 hours *flying* time, ignoring any time on the ground when you stop over somewhere in the middle. It's a good job I enjoy reading on flights
NetApp are being somewhat inconsistent. Their technical presentations and their website differ (possibly because it is more straightforward for them just to say "yeah, RAID-DP is RAID-6" because it is easy to understand).
If you consider RAID-6 to be the generic term for any dual-parity RAID protection, then sure, RAID-DP is RAID-6. However, the technical implementation is more like RAID-4 with two different parity calculations. The parity disks are dedicated rather than distributed.
The failure mode that is easiest to manage is when they completely fail.
Good luck to you with disks that fail silently over a long period of time, corrupting your data without you knowing about it.
Some correct fixes for this are combinations of RAID, backups, a filesystem that checksums data and metadata (BTRFS, WAFL, ZFS). Limping along on half knackered drives is probably one of the worst things you can do.
MAC address filtering is useless against a determined attacker. Your best bet is a WPA2 PSK with a long key, unless you fancy setting up WPA2 Enterprise.
Or, instead of thinking better of mugging little old ladies, Mike now carries a gun himself. Because he's a drug-addict, he doesn't adopt the same decent moral stance that you do on the use of guns. He's quite happy to shoot, because he's a used to an environment where little old ladies are legally able to pull out a gun and shoot him in the face.
It's my belief that by permitting guns as part of normal everyday society, an arms-race is started. The "bad guys" aren't worried about the legal use or ownership of guns (they're the bad guys remember, what's the problem with breaking just one more law!), so they're nearly always 1 step ahead.
HELP!!!! I'm being held prisoner in /usr/games/lib!
