Imagine a lock and key. You can picture this mechanism and have probably known how they interact together (at least at a high level) intuitively since before you can remember. The lock protects a physical resource from theft, vandalism, or other tampering by restricting access to anyone without the corresponding key. The weaknesses to the lock and key system are also fairly intuitive. Lock-picking, brute force, key theft or duplication, etc are all ways to bypass this type of security mechanism. Thus it is obvious to basically everyone using a lock and key that in order for the security to be effective they need to take precautions regarding the key. To be safe we avoid unnecessary duplicates, use different keys for different locks, and often use redundant security mechanisms like alarm systems and a police or security patrol. ...More
Systems development and architecture teams have been here often. They find they must sacrifice client expectations for system security or the reverse and put client expectations ahead of security. This is the root cause of the recent IoT DDoS that took out significant portions of Dyn’s DNS infrastructure. This attack brought Twitter, Reddit, Netflix, and Github, as well as many of Dyn’s other clients to their knees. This attack isn’t the fault of Dyn or its clients, instead it is due to the proliferation of a “ship-it-unfinished-and-patch-it-later” mentality that has burdened software development as systems and public consumers of those systems have multiplied. Specifically, tying release date deadlines to marketing or wholesale orders means feature fulfillment will push security out of precedence every time. In this case ~100,000 webcams with default hardcoded administrative passwords coupled with ISPs and long haul carriers failing to filter spoofed packets was enough to DDoS many of Dyn’s subscribers. ...More
subscribe via RSS