I bought a few books lately on Amazon - one of them is The Elements of Computing Systems: Building a Modern Computer from First Principles - at the end of Chapter 1 it asks you to design all the gates you're going to use starting with primitive NAND gates (but you can use gates you've already designed). I started reading the book because I wanted to more deeply understand assembly language, which I'm trying to pick up again.
In designing the gates, I think I'm taking the wrong approaches, because my designs are not as minimalist as they could be first out of the box. When I designed my OR gate, my first design used 3 NOT gates (basically one NAND gate with the inputs tied to one pin) and an AND gate (2 NAND gates). That design, when I drew it out - it was immediately obvious that I had two redundant NOT gates (as the AND gate ends with a NOT gate), showing me that the correct design is 3 NAND gates for OR.
The doubts are starting to creep in - my first attempt at XOR design came up with a non-symmetrical drawing of 6 NAND gates (based on the logic of using one OR and one NAND and ANDing the result). Looking on the web, though, 4 NAND gates are needed, not 6, and looking at my design, I still can't SEE the redundancy. I'm hoping that something will click and I'll keep staring the problem down until I really GROK where that redundancy is...perhaps I'll go redraw my original circuit symmetrically and that will help.
Randomblings from Rich - Random talk about technology, science, chess, news, hobbies, stupidity and myself.
September 25, 2009
September 10, 2009
Stop Assuming Security
Let's all just stop pretending that our connected applications and networks are secure. I mean, it, just stop it already. I don't care if you're PCI Compliant, use SSL with AES encryption and SHA-2 hashing algorithms. You can have IDS in place, and a 24-hour monitoring system with armed guards and Predators with hellfires ready to rain down fire on anyone that dares ping your DMZ. You're not secure....and you never will be.
Instead of approaching system security from the system side, we need to look at why the security is in place and begin architecting one-way data funnels into our connected systems. Once I've processed your credit card transaction, why do I have to continue storing your card on a connected data system (or store it all - but that's a different discussion). If I need to store vital information about my customers, the data system I do this on shouldn't be connected to anything, and it certainly shouldn't be accessible to any system connected to the Internet. System architects need to take much of the blame for system vulnerabilities because of the system design itself. Data is stored too close to the Internet, and easy and cheap interfaces like ODBC connections to our internal databases are too often shortcuts taken for saving money on development of single-use one-way data connectors.
In fact, system developers need to be woken up to the need for development of low-capability software, and how this software can play a vital role in secure system design. Why don't we see write-only database connectors on the market? How about packaged systems that have limited functionality (no-database read-only web server systems)?
We need to automatically assume that whatever multi-use software we are using is insecure and start limiting our exposure to vulnerabilities by removing capabilities that we don't want from our designed systems. When (not IF!) those vulnerabilities are discovered in our systems, the exposure risk will be limited to the capabilities of the software (and maybe the hardware!?!) that we use in designing the system. If the system is incapable of writing to the disk system at all, then when it gets hacked, the vulnerability won't expose the risk of writing data. If our customer service page gets hacked, if the page has no capability for querying the database through the one-way 'deposit-only' data connector, then the exposure will just be that they can write junk to our database. If our database is incapable of running shelled commands, they won't be able to do so.
Perhaps it's time for security analysts and software security architects to get religion...Luddism
Instead of approaching system security from the system side, we need to look at why the security is in place and begin architecting one-way data funnels into our connected systems. Once I've processed your credit card transaction, why do I have to continue storing your card on a connected data system (or store it all - but that's a different discussion). If I need to store vital information about my customers, the data system I do this on shouldn't be connected to anything, and it certainly shouldn't be accessible to any system connected to the Internet. System architects need to take much of the blame for system vulnerabilities because of the system design itself. Data is stored too close to the Internet, and easy and cheap interfaces like ODBC connections to our internal databases are too often shortcuts taken for saving money on development of single-use one-way data connectors.
In fact, system developers need to be woken up to the need for development of low-capability software, and how this software can play a vital role in secure system design. Why don't we see write-only database connectors on the market? How about packaged systems that have limited functionality (no-database read-only web server systems)?
We need to automatically assume that whatever multi-use software we are using is insecure and start limiting our exposure to vulnerabilities by removing capabilities that we don't want from our designed systems. When (not IF!) those vulnerabilities are discovered in our systems, the exposure risk will be limited to the capabilities of the software (and maybe the hardware!?!) that we use in designing the system. If the system is incapable of writing to the disk system at all, then when it gets hacked, the vulnerability won't expose the risk of writing data. If our customer service page gets hacked, if the page has no capability for querying the database through the one-way 'deposit-only' data connector, then the exposure will just be that they can write junk to our database. If our database is incapable of running shelled commands, they won't be able to do so.
Perhaps it's time for security analysts and software security architects to get religion...Luddism
Subscribe to:
Posts (Atom)