Application security is the use of software, hardware, and procedural methods to protect applications from external/Internal threats.
GiBu GeorGe
Deploying a new web service and we want to make sure its damn secure.
What all you should have
- Development life cycle
- Risk management
- Change control management
- Necessary standards, policy’s and procedures
Goal: This things need to be avoided.(OWASP)
- Injection
- Broken Authentication and Session Management
- Sensitive Data Exposure
- XML External Entity
- Broken Access Control
- Security Misconfiguration
- Cross-Site Scripting
- Insecure deserialization
- Using Components With Known Vulnerabilities
- Insufficient Logging and Monitoring
more from bellow url. Check it out
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Software Development
Cannot stress strongly enough about the important of Security in development life cycle, Developers misses a lot there goal is not always security and comes as a after thought, And skills of developers vary a lot “a loooot”. Find security bugs way later in production compromises the release cycle, Been said If you have a strong SDLC practice with security and risk assessment involved on relevant stages. You should have a strong software code.
Testing Environment
There are lot of options while creating a test environment mostly you already have a testing environment, Demo, Staging and production.
Virtualization in company private cloud or VM farm In small company you can use public service like aws(get in touch with them if your security testing on there resources). Isolate the testing environment. Or my favorite if non above exist do a local VM network with Virtualbox, Vmware, Xen or KVM you have a lot of options and control.
What you should be familiar is Static testing and Dynamic testing the web application, Check software source code for developmental security errors and if error are found is loaded back to bug tracker depending on your SDLC, Also test the application is in running state, put servers logs into debug mode. Logs are your best friends here. Find as much bugs as possible as an insider you have more resources available to you than a attacker.
When Creating a Local Testing infrastructure we are trying to find as much flaws as possible and feed it back to the development process to be rectified
Before Production after testing: Administrative stuff
Properly configured process you don’t have to go blind in configuring demo or staging servers, There will be a procedures and standards regarding Operating System to use how it should be configured
Web Servers and Critical Service
Two installation method is source and binary, I would recommend source installation(helps in better control on changes, but if there is demo configuration process you have to follow, then that one) . check what all modules and features are needed, compile and install the web server with just what we need. Try to get the staging as close to production as possible, follow your organization security policy regarding testing environment.
Getting a baseline to configure IDS and IPS
There are lot of IDS and IPS available lot of good opensource one more maintenance required as you’re the support no external support or updateded rules, free rules are usually delayed or paid ones are damn expensive for a SMB, there are lot of commercial solutions also.
Mod security is a great place to start, Its a tiny module which can be loaded to web server and configuration can be done in any scenario we can come up with, Then there is OSSEC and SNORT also great, I am going with open source here with free rules. I mostly use a combination of there three with layer defense approach, and built upon it.
While testing on demo, place the IDS IPS etc in detection mode check logs, Simulate traffic. if any anomaly detected, check for false positive, determine how do you want to solve this System/Network Administration way or development way, later is preferred if its a genuine risk, if a false positive we can go with System/Network Administration fix.
While creating a baseline of good and bad traffic to train the security software this could be overwhelming. Using good traffic as a baseline and blocking rest is far easier and building on it much simpler. We can easily compare with good traffic in production and change can be made accordingly when in production.
Security testing on Demo: Continues
Always make sure you have necessary verifiable permission for what your going to do.
Try brute-force the application. Do full fledged web application pen-test with opensource tool. Try to take server down, Be destruction and through as possible on test server. Set the data from IDS, IPS, Create a baseline for possible attack and normal usage. If vulnerability scanning baseline and procedure is available use it for scanning to adhere to use case scenarios.
How to configure production
You don’t need to configure production you already have a production, Deploy it after making necessary arrangement you will be good to go if change has been properly documented if needed to revert after real traffic cause any problem.