44

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.

user230910
  • 1,005
  • 1
  • 11
  • 12
  • 64
    4h per month? Give up. It's not enough to read the code on anything not trivial. The application will be hacked and you will be blamed... – ThoriumBR Nov 01 '19 at 02:31
  • 21
    Spend that 4 hours to hire a 3rd party and review their performance. I think even 4 hours a week is too little. – Nelson Nov 01 '19 at 02:31
  • 34
    "I have 4 hours a month to eat. What should I eat?" If the whole list represents the list of things that would *not* be done, then you need to work with management to increase resources. You need to perform a *risk assessment* to determine the imoact of not doing any one of those things, then prioritise. – schroeder Nov 01 '19 at 07:45
  • 6
    I realise you are not after technology-specific answers, but you mention C# Web API without mentioning the hosting of it. The hosting of this would dramatically alter the approach for security i.e. if it were a PaaS: App Service Plan you would have far less to cover than IaaS VMs for example. You are probably already aware, but some discussion of this can be found: https://docs.microsoft.com/en-us/azure/security/fundamentals/paas-deployments which may be useful when talking with stakeholders. – Alex KeySmith Nov 01 '19 at 13:03
  • 9
    You've got about 10 minutes per day at that rate. Spend them telling your superiors that "we're going to get hacked, bad, unless more resources are assigned to this." That should take about 10 minutes per day (and you do this every day). If you're lucky, you'll burn through an entire hour on Monday and you'll have exhausted your weekly time-budget. Finish said meeting with "well, there goes all the time I have this week keeping the application secure. Sure hope someone doesn't hack us tomorrow, I wouldn't have time to fix it until next week." – Draco18s no longer trusts SE Nov 01 '19 at 17:27
  • 3
    While I enjoy sarcasm as much as the next guy, I was hoping for some thing, anything I could do to actually make the app safer. – user230910 Nov 01 '19 at 20:12
  • 2
    To be clear, do you mean that you have 4 hours to make changes to the production environment, such as installing an upgrade? Do you mean you have 4 hours of *your time* per month, so, like, you could start a scanner (let's say 10 min), then read the results (let's say 1hr 50min), then present the results to management (let's say 2hrs)? Or do you mean that there is a 4hr time window, once per month, outside of which you are strictly prohibited from spending any resources related to securing this system - so if you start a scanner and it takes 4hrs to execute, you're already done? – atk Nov 01 '19 at 22:46
  • 4
    You are being set up for failure. Please tell them there is absolutely no way to secure this thing. Companies with multi-person, full-time security teams fail to prevent hacks. There is no way to make this work and they will blame you entirely when this explodes in their face. – zero298 Nov 02 '19 at 04:56
  • 2
    4 hours a month could be a reasonable time allocation for maintaining the security of _a third-party application_ that your company is using. You'd use the time to monitor security alerts for the app, installing security updates as soon as they're released and making sure that your coworkers can't compromise the app with insecure configs. But that only works because the developers of the app are doing 90% of the work. And you'd still need extra time up front to review the initial installation, and any actual security incident or breaking upgrade would almost certainly blow your time budget. – Ilmari Karonen Nov 02 '19 at 11:32

9 Answers9

45

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Izy-
  • 853
  • 1
  • 8
  • 17
  • The one thing that I think is assumed in this answer is that it is not 4h once off, it's 4h EVERY month. So the first month MFA, DR etc, the second month could probably just be a quick test of those things? – user230910 Nov 01 '19 at 20:25
  • 1
    @user230910 you're right! I think this was more of a plan for the first month's 4h. I would recommend first focus on the above, the next month focus on having some DoS protection in place and start laying down second lines of defense like encrypting data at rest, ensuring sufficient logging, etc. And then start looking for anomalies within the system. As you go down the months, you'll have less to implement and more to "check the straps". But don't forget the documentation! It's a great habit to start from now and will help you (and the next guy) loads later :) – Izy- Nov 02 '19 at 03:28
27

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:

  1. managing your VM updates as Azure doesn't push Windows updates automatically
  2. making sure to setup processes for important cloud operations such as patch management, backup, incident management, change management, emergency user access, privileged access;
  3. enable password management and use appropriate security policies to prevent abuse;
  4. 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

LLub
  • 1,246
  • 10
  • 21
  • 2
    +1 for giving actionable advice instead of telling the OP "there is no way". Sometimes the situation is simply #&^$ed and a way must still be found... – fgysin Nov 11 '19 at 14:41
8

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.

Community
  • 1
Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • 2
    This one really nails it. With the amount of time given you cannot really help the owner's lot, but you should use it as an opportunity to improve yourself. – postoronnim Nov 01 '19 at 18:43
  • 3
    Doing work on your own time is admirable, but ill advised. The consequences could range anywhere from a good talking to by management to the company being audited, depending on the nature of the work being done. – Draco18s no longer trusts SE Nov 02 '19 at 02:36
  • 2
    @Draco18s I've literally never worked for or heard of an employer where free overtime is anything other than encouraged. I could see it being a matter of jurisdiction of employment status though. However, If you happen to work in a crazy place where they react negatively to free overtime, ignore this advice. – Conor Mancone Nov 02 '19 at 04:27
  • Free overtime is giving yourself a bad deal. Why do you think because OP has one very small part of their job to do security-related things, that they would want to change their entire career path based on it? – Nacht Nov 03 '19 at 21:49
  • My boss has made unrealistic demands is never a good reason to work over-time – Jasen Nov 04 '19 at 07:22
6

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.
Bergi
  • 277
  • 2
  • 10
4

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.
ChrisFNZ
  • 141
  • 5
3

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.

S S
  • 39
  • 3
3

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.

kubanczyk
  • 1,182
  • 6
  • 11
1

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.
Blerg
  • 540
  • 3
  • 4
  • 1
    Thanks for the answer, but I'm a little confused as to WHY this is a good approach? What does it guard against? What should I look out for? I could probably script this whole operation.. – user230910 Nov 03 '19 at 23:39
  • 1
    It removes the 4 hour window for security checks. Instead of only working on the server for a short amount of time, you now have a separate server group which you can hammer away to your hearts content. If you find something that crashes/compromises the server, it's not the production server, so just restart and continue on. If you break the server, restore your latest backup. Since it's not production, customers and management won't see anything. Keep those databases from seeing other IP addresses, or unwanted changes might find their way to them. – Blerg Nov 03 '19 at 23:55
  • Ok, thanks for explaining! :) – user230910 Nov 04 '19 at 00:14
0

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.

chrishmorris
  • 129
  • 2
  • 8
    (not the downvoter). I don't think this is reason to start polishing your CV. Setting aside 4 hours a month is a pitiful amount of time for a company to spend on security, but it is still 4 more hours a month than most companies put aside for security. They are at least giving some thought to security, which (sadly) puts them ahead of the curve. They certainly aren't going to end up with *good* security, but they are no more likely to go out of business than the next guy... – Conor Mancone Nov 01 '19 at 16:19
  • 5
    When the options are 1) updating code, 2) designing DR, 3) backups, 4) vulnerability testing, you don't go for *fuzzing*, especially if you assume that no one will listen to the test results. – schroeder Nov 01 '19 at 16:30