If you are not using someone else's proven platform, then yours will be hacked, possibly several times, at least until you've learned how to secure it and have

If you are not using someone else's proven platform, then yours will be hacked, possibly several times, at least until you've learned how to secure it and have kept it secure for some time. With that in mind, you must, must, must do a few things: 1. Get really, really good at rollback and recovery. Make sure you can completely rebuild your operation from a clean system in as short a time as possible, with no data loss. Certain types of compromise will require this, it will be the cleanest, safest way to recover. 2. #1 requires you to be really good at backups. Unless you have experience here, they're harder than you think. 3. Notice that #1 starts with "rollback": You will occasionally be your own worst enemy, at least until your release processes get really, really good. Every now and again you will apply something that breaks something else. Being able to get back to a known good state quickly and easily will save you countless hours and much stress. 4. Find an experienced penetration tester that you trust implicitly. Have them review your operational architecture; they will find flaws (that's just on paper). Have them review your hardware and software configurations; they will find flaws. Listen to their proposals for risk mitigation. Once you have a system that passes their paper attack, have them actually kick at it, from three different places: one, from the outside, from the Internet everyone comes from; two, from just inside, from within your first tier, between outside interfaces to the world and app logic; three, from deep within, behind the app tier (using test data, of course). The three reports should be very different, with increasing levels of access and vulnerability as they go (because you are letting them past the mitigations). This will give you considerable information about how at risk you are. (I know quite a good one, does this sort of thing professionally for government, private sector, the military, police forces, etc. He'll break your stuff. And tell you how to make it better.) 5. #4 implies, strongly implies, that you have a restricted access test environment that matches your operational environment as closely as possible, with two exceptions: one, no production data; two, it may be a patch or two or a major update ahead of production, since it's where you will soak changes to make sure they work properly and break nothing. 6. Managing #5, #3, and #1 means you must, must, must understand and get good at change management. And risk assessment and risk management. IT Security is mostly about governance and management. If you focus on technology first, you've already lost.