I have just 4 hours a month to security check a cloud based application - How to use my time?

Question

I've been tasked with looking after an application deployed to azure. I have been allocated 4 hours a month.

I essentially have half a workday to secure this application / keep it secure. What is an efficient use of my time?

Should I concentrate on:

• Making sure all the components are up to date?
• Checking all the logs to make sure nothing is looking dodgy?
• Attempting to "hack" the application myself?
• Documenting the system in detail from a security perspective?
• Researching current vulnerabilities in this/related tech?
• Ensuring backups etc are working correctly?
• Disaster recovery stuff?
• Creating policy around "being hacked"?
• Auditing the source code with some tool to search for bad patterns?

Or some combination/something else?

I'm looking for experience based answers, preferably from someone that does this kind of security maintenance. If there is any kind of existing best-practice/guideline that would also really help.

The technology stack is:

• SQL Server Database (Azure SQL)
• C# Web API
• Angular Front End

There are several additional components, but I'm not really looking for tech specific answers, more a strategy on how to approach this.

Answer 1

Start with the Azure top security best practices so you can maintain and improve security of your Azure solution step by step:

1. agree and upgrade your Azure subscription to Azure Security Center Standard. This will help you find and fix security vulnerabilities, apply access and application controls to block malicious activity, detect threats using analytics, and respond promptly to attacks;
2. store your keys, database credentials, API keys and certificates in Azure Key Vault. Additionally make sure keys and secrets in the solution are not stored in the application source code;
3. install a Web application firewall (WAF) that is a feature of Application Gateway and provides protection of your web application from common exploits and vulnerabilities;
4. enforce multi-factor verification for your administrator accounts;
5. encrypt your virtual hard disk files;
6. connect Azure virtual machines and appliances to other networked devices by placing them on Azure virtual networks;
7. mitigate and protect against DDoS with DDoS Protection Standard that provides additional mitigation capabilities;

When you are ready with the 1-7, focus on:

8. managing your VM updates as Azure doesn't push Windows updates automatically
9. making sure to setup processes for important cloud operations such as patch management, backup, incident management, change management, emergency user access, privileged access;
10. enable password management and use appropriate security policies to prevent abuse;
11. review your Security Center dashboard to maintain an overview of the security state of all of your Azure resources so then if required you can take action on the recommendations;

Read the Microsoft documentation on the Azure security best practices.

Documentation:

Microsoft Azure Security Fundamentals

Microsoft Azure Security Documentation

Answer 2

As mentioned in the comments, I too agree 4 hours in a month is way too low. Understand, and more importantly, make your stakeholders understand that with 4h they shouldn't expect much. Considering they've given you 4h, it doesn't look like they're serious about securing this application either.

Based on the comments, answers and my own thoughts I'll try to put together something. Here's how I think your options should look like in order.

1. Ask for more time. Make them understand if they want to secure an application in just 4h, it's practically useless.
2. Hire an agency and spend your 4h defining their scope, prioritizing their actions and reviewing their results. (@Nelson)
3. If you can't do the above, I'd recommend securing the low hanging fruits so you're covering more ground in 4h. Here's what I think are important
   • Set your external facing services to update. (~1h to find and set the important applications for update). Close unnecessary ports/services that you don't find useful.
   • Set up MFA (~10mins) - since you don't have much time, set up things that are quick, protect you against common attacks and alert you.
   • Review your secrets - Ensure they're stored securely, run scanners on your code to find hard-coded secrets. (~1h)
   • Disaster Recovery - I'd recommend spending some amount of your precious 4h in setting up protections for when things go wrong, because they will. Start creating backups (2 if feasible) in different zones. I'm assuming the platform will help you with this but it will still take time. During this time, you can also draft out a rough disaster recovery plan. (~1.5h)
   • Finally, with whatever little time you have left, document. Document what you've done, what you haven't done and what should be the next steps for the next time someone gets 4h to further secure the application. (~leftover)

DoS protection is good and required but I just couldn't find a way to fit it in to the above plan and neither could I swap anything out for it. Maybe that should be documented in your next steps.

Overall, it's a farfetched request to secure something in 4h. But if I were tasked with it, I'd do it with the above steps. I'm not sure if any investigations into whether the system is already hacked is feasible in those 4h. When you are given 4h to secure, you can either chose to spend it in securing the application against potential threats or investigate for attackers in your system (needs a different plan). That initial choice is yours.

Answer 3

This is a very out-of-left field answer (aka it has little to do with actual security), so feel free to ignore my advice. This question itself is fairly opinion-based, so I thought I'd try a completely different "kind" of answer.

You've been put in charge of application security. This is a good thing!

Unfortunately, your employer has very unrealistic expectation of what is required to secure an application. 4 hours is no where near enough time to do this job well. To be clear, this is still better than most companies (that assign exactly 0 hours per month of dedicated security time). The reality though is that 4 hours is a pittance. So this is what you do:

1. Run with all the suggestions that people give here
2. Spend much more than 4 hours a month
3. To avoid making your employer unhappy or directly disobeying orders, do the extra work on your own time. Plan on spending the next few months working a good chunk of extra hours on a regular basis.
4. In this time you'll get to learn about things like reviewing code for security weaknesses, installing and using SEIM systems, installing and using logging systems (ELK stack is commonly used), intrusion detection systems, automatic application scanning, and more! (the full list is probably too long learn it all in a few months of work in your spare time, but do your best!)
5. Your company is going to end up with the benefits of your free labor, which is a bit sad, but...
6. You will be well on your way to training yourself to be a security professional (if you wanted a job title, you're on your way to being an Application Security Engineer) as part of your official duties, securing an actual web application in production use!
7. Start applying for your next job as an Application Security Engineer. You'll probably find a better job doing work that is more fun, and you'll probably get paid better too!

Obviously I can't make any guarantees about how things would turn out, but effectively what you have been given is permission to start training yourself for a career change. An opportunity to invest in your future! Security professionals are even more in demand then engineers, so personally I'd take this and run with it. Especially if it worked out in my favor, I wouldn't even begrudge my current employer for the free work I was going to give them due to their shortsightedness.

Answer 4

I would suggest to

1. Start with doing a risk assessment
2. Compile the lists given here (both by yourself and in the answers) into actionable items
3. Go back to your superiors with the result and ask for either more time or a prioritisation by them.

Answer 5

As others have already mentioned 4 hours is way too little effort but I'll provide some recommendations in case you find them useful.

• Run a vulnerability scanner such as Qualys or similar. This will pick up a number of useful app vulnerabilities such as XSS, SQL injection, CSRF and similar.
• Run a code review tool to identify any obvious bad practices (ie not escaping user input properly before sending it to the database)
• Install a good internal (host based) and external (edge or cloud based) WAF that protects against OWASP threats and more. Several cloud based WAFs will protect against DDoS and some brute force attacks as well.
• Isolate your infrastructure into vlan zones by trust and ensure minimum dataflows between them (e.g. Edge, Presentation, Business logic, Data)
• Someone else mentioned it before but very important: ensure you're storing privileged credentials (API keys, db creds etc) separately from source code.
• Harden all infrastructure.
• It may take some time but I'd recommend you produce a heat map or balanced scorecard of security risks and ensure it's visible to your senior stakeholders. Good security practices can reduce risk but none is a silver bullet on its own.

Answer 6

I am going to assume the application is extremely small, you write scripts for the logs to search for things out of place (ideally this is not done during the 4h work period), disaster recovery should already be in place for a major application (check if the application requires such an effort.).

1. Documentation is vital as it should let you know what is used and who uses it also how often it is used. This will help when developing the script.

2. Scripts are needed to condense a month's worth of logs so choose carefully.

3. Check backups.

4. Always check the technologies used and if there are any POC or exploits. Do not jump into it and start attempting an exploit yourself, you have only 4h.

5. Request for additional support if the application is vital.

Ideally only the documentation and scripting should take time rest should be fairly straightforward. This is not the best you will have to determine the worth of the project and choose if 4h is enough.

Understanding your target helps you protect it better.

I am sure there is a better answer hopefully they will provide it.

Answer 7

OP, it looks like you're mainly a developer, looking at your contributions. So what can a developer do to increase the security?

In the first month:

• 2 hours: Attempt to bump a version some external dependencies/components/libraries and try to re-build the app. Document the incompatibilities if you fail.
• 2 hours: Do whatever is needed to push your own changes through CI/CD, through testing, through master branch, and to production. Do try to piggy-back other development if there is any, but in this case pay special attention to leave trails that you've actually did something useful (e.g. author some PRs).

Repeat every month but adjust the division line between the two as you go. (Chances are that the final split will be more like 10 minutes versus 3 hours 50 minutes.)

This way you fix the worst vector - that one of popular components/libraries has a months-old published vulnerability (CVE). Swarms of bots start to scan the entire Internet pwning every vulnerable deployment. If you just upgrade the third-party components, even only by making (informed?) guesses, there is a decent chance that you will never become a victim and will never need to handle the truly unpleasant situations.

That's quite trivial for developers, but in most companies developers avoid such uninteresting maintenance. It's becomes a big issue for the typical security departments (as they don't re-compile applications). The grand efforts to "analyze logs" or "implement WAFs" or "perform vulnerability scans" are there mainly to cover that gap from all remaining possible angles.

---

From your question, it looks like you are asking how to focus your learning. I'd like to challenge that assumption here and now. Whoever allocated you 4 hours per month already cut off their own application from benefiting from your self-education. Irresponsible of them! To learn something dedicated to this project, then implement it, then learn on your errors and iterate... That cannot be done in 4-hour chunks each month. Don't "fix" this, because it wasn't your decision! In this project's time do things that you already know well.

That's a starter. What you try to learn and implement in your own free time, is your preference and your own business. I think it's too broad for this site (as it may be that you decide you are not interested in security, which is totally fine), but others gave you tons of leads anyway. Look for useful things during your other projects as well. Some of the former or the latter will fit into these 4 hours and help to improve the state of the project.

Answer 8

From a systems administrator who's had to do such things, I'd recommend just creating a dev VM which you can swap out with prod.

1. Backup your server.
2. Separate your databases onto their own servers. Make sure that they can only communicate with ONE IP address, the production server/service that needs it. (One time change, very important.)
3. Clone the main server and give the new one a different IP address.
4. Make all necessary changes, updates, reviews, and checks.
5. When the 4 hour window is available, bring down the services on the main.
6. Backup databases. CRITICAL STEP.
7. Push all local changes from main to cloned.
8. Ensure everything looks good and is working properly.
9. Swap the IP addresses for main and cloned.
10. Cloned is now main.
11. Make another backup of everything. (Yes, do another one.)
12. Bring up the services on main.
13. Leave the other system alone as a backup in case anything happens.

Answer 9

You don't mention the risks: does it store personal data, etc. But if it is a complex application, then one approach that is quite time efficient is fuzz testing: extract some valid requests from the logs, mutate them with the sort of metacharacters that could be in an injection attack, and report a vulnerability every time you get an error 500.

Sadly the usual response is "that's not exploitable", especially in a security-naive environment like you seem to be. And turning a vulnerability into an exploit takes more than your budgeted four hours.

Alternative answer: spend the time polishing your CV, because this employer could go out of business any time.