“Don’t use client-side authorization” is a well-known security rule. Or at least it should be. I went looking for a canonical reference for it, and could not find one, so I wrote one. Please comment if you know a better reference for this!
I am occasionally asked by our clients to measure how secure a thing is. That is perfectly reasonable to want to know. Is it secure enough? Do we need to spend more on security to make it secure enough? Are we getting better or worse? And so, managers are surprised, as well as disappointed, to learn that measuring security is nearly impossible.
We present new research that details crucial security weaknesses in Linux software that has been statically linked. We also provide a solution to temporarily resolve these security issues. Finally, we conclude by demonstrating how to have both RELRO  and ASLR  security mitigations working with static linked executables in the ELF format.
I have been designing secure and security products for 20 years. I always thought of this as “architecture” and it took me a long time to realize that a major part of what I was doing was threat modeling. There are many established approaches to threat modeling, but because I backed into the field, I had rolled my own. This post is to explicitly describe what I have been doing.
Risk management is a fundamental requirement for all major information security frameworks, but there is little practical guidance for implementing a risk management program at small or young organizations. Existing risk management practices require varying levels of staff, expertise, tooling, and time — all expensive — as well as a mature concept of risk, when none of these necessities may be available. Consequently, there is an industry-wide need for a “minimum viable program” that allows organizations to manage risk despite lacking the prerequisites for more full-featured risk management programs. This white paper outlines such a program.
You’ve got frustrated users, availability and confidentiality issues. All from a temporary workaround that wasn’t fixed when it was relatively easier. Welcome to technical debt and the interest is accruing. Where non-kludged systems can be patched and upgraded within regular service windows without the entire IT department on call, fixing this monster will require serious planning.
If you were under a rock for the last few weeks, WannaCry is one of those cyber-security events that made it into regular news. If it hits NPR, that means everyone who knows me or at least strikes up a conversation at the bar will ask me my opinion.
If you're like many of our clients, you're in customer acquisition mode. You've spent a bunch of money to build your product or service, and the marginal cost to support a new customer is relatively small. They're buying the same thing everyone else is, so there's some additional load you need to meet.
Passwords, as a security solution, have become untenable. Whereas 15 years ago you might only have needed to remember two passwords, your ISP or your work password, now we have a plethora of passwords to keep track of. Power utility websites, water utility websites, bank websites, online payment websites, Facebook, Instagram, Twitter, Pinterest or any number of other sites that have our information. The guidance has often been to make passwords complex, alphanumeric, contain special characters, be as long as possible, oh and make them easy to remember but don’t reuse passwords and never write them down.