jlkinsel

While it is great, Wazuh is not close to a static analyzer.

Actually, the www was working. It's a cname to tp.47cf2c8c9-frontier.amazon.com, which should have been a cname to d3ag4hukkh62yn.cloudfront.net, but that record was broken for about 20 minutes.

Update: that frontier cname seems to be bouncing between Cloudfront and Akamai now, so I suspect they're fighting off either an attack or internal issues. I see issues to other route53 servers as well.

I think that was a message from the rebel base?

sudo, ssh certs, egress firewalling. Congrats - you've covered about 4 pages from the NSA's 200 page hardening benchmark. Off to a good start!

http://www.nsa.gov/ia/mitigation_guidance/security_configura...

I've seen more compromised boxes than one can shake a stick at. There's all sorts of reasons that blocking egress is a great idea. Compromises are usually automated bots, and no, they're not smart enough to bring down iptables. Even if it's a human that's pwned you, it's frequently a stupid human, or a lazy human. It's just good practice to practice security in depth.

Time to write a little VBScript to port scan me some Dropbox servers...

Soo they didn't forsee how teh hackers would compromise accounts without 2FA...but passwords are dead.

Well, I for one, am sold!

To go a little further - at a glance, it's not clear if they've been fined yet or not, but either way there's soft costs to all of this - being in the news in a negative light, some patients will go elsewhere, their insurance premiums are going to go up as a result of the breaches, etc etc.

Last year when KC shot themselves in the face, they were running trading algos that hadn't been well tested. When dropped into production, things blew up fairly quickly.

I probably should have left it off the list, it's more of a compliance/procedural issue than purely infosec.

Stanford's a little more than a college. There have been at least 5 HIPAA breaches, with at least 70k people's information compromised.

http://www.healthcareitnews.com/news/stanford-reports-fifth-...

man how'd I forget hb gary...that's my other favorite

Let's see...

TJ Max, UBS, Knight Capital, Heartland Payment Systems, Visa, Sony (already mentioned, but it's my fave), Stanford, Countless other hospitals, e-commerce vendors, banks, and other organizations that handle payment or personal information.

If you want to say "name a startup that's gone out of business because of a security problem" I'll let you away with that. There's still instances, and I'd love startups to pay more attention to security, but I know reality as well...

I'm a little surprised this is on HN? To me this is the equivalent of a blog post about using %d with printf.

Not complaining, just a little surprised something so novice would get attention...

A problem for security geeks is they frequently forget about 2 things: 1) the balance between usability and security, and 2) The risk acceptance/appetite of the person for the security they want/need to use.

The two are intertwined closely. For something that isn't that important, a user isn't going to jump through complex hoops every time they have to login. What they will end up doing is finding workarounds (Hello Mr. Post-It).

For most folks, they don't really need complex solutions to reset their email password. What needs to be asked is "What am I protecting, and what is it worth to me?"

Oh, and I'd suggest certificate-based auth is way better than complex passwords.

Daniel's been around for a while (I've loved OSSEC for years) so I suspect this post just wasn't meant to be a complete essay on the topic...

In theory if your'e going to the trouble of having different OSes on the two systems, you'll have separate admin staff, as well...

Yeah...this is nice, but really who's gonna implement it? Only folks with a lot of resources and need to protect something more serious than passwords on a social network.

Or organizations who are vulnerable to the RSA sales person attack. ;)

As others have hinted - once you have folks sophisticated enough to do tricks like using multiple operating systems, you'd hope they're going to catch the basics...

I say the post is nicely done, and note that I'm happy he took security into account, and people downvote. WTF???

Hmm...that seems to have potential, but it requires custom integration and users to use your app.

Is there an open protocol for this?

Looks like you're doing something similar to the mutual auth that wikid does...a whitepaper or two with more depth would be useful on the site

Nicely done. I was worried when I saw the headline that he wasn't going to take security into account...

I use a safari/firefox mix, all that's in that db for me is a short list of things I don't care about...

What's the Apache source code?

You mean Apache httpd? :)

Realize "Apache" means the Apache Software Foundation, which is made up of a large collection of open source projects.

(disclosure: Apache CloudStack contributor and PPMC member)

I've become jaded with "top 5" style lists recently, but this one's pretty nice. I'm doing a few "secure development" training sessions with development teams in the next week, will be referencing this for sure.

I'm not sure writing tests makes you a better developer...gives you better habits, but not sure it results in your code being better, compared to things like fixing bugs in others code and learning a new language.

The learning a new language holds true past software development - when I learned Spanish in high school, my understanding of some of the stranger forms of English (say, past participle) improved.

This is a UNIX cheatsheet. Nothing devops about it.

And I concur with the comments about "sudo !!" - !! in general I've totally removed from my UNIX vocabulary. At least do something like !?string[?]

Does CookiesOK do any type of moderation over the cookies? Checking for domain scope, cookie flags, reasonable expiration of the cookie?

I understand that "free" sites need advertising revenue, and unfortunately a lot of ad networks want to track my every move - how about enforcing a compromise where cookies are allowed for X minutes after I hit the page?

Security-wise, I'm more interested in enforcing that cookies sent over SSL are not readable via standard HTTP. This tool is a step in the right direction, but I think a few more features would make it pretty attractive.