Budgeting for Techies: How to Get Money for a New Security Tool

Budgeting for techies

How to Get Money for a New Security Tool

We all know the common answer when asking for a new software tool: “sorry, no budget”. But why is that? Often because we, as technical oriented people, simply don’t know how budgeting works. Not surprising, as no one taught us. The downside is that it limits us seriously, to obtain the right tools for the job. Time to combine tech, money, and skills, to get finally that new tool you wanted!

Why budgeting?

Most bigger companies have a formal budgeting process in place. It is actually a security measure, to ensure that financial risks are kept under control. And guess what, this is also why there are “controllers”, people who manage the budgets. Besides them, a big company may also have a Chief Financial Officer, or CFO, responsible for the financials of the company.

Operations

On the operational level, the budgets are usually managed by IT managers. They have actually a difficult challenge. Their job is to ensure that the IT environment is running stable, while avoiding money draining too quickly. This brings us to the next point, forecasting.

Budget forecasting

Let’s say you are a manager and responsible for a team of engineers, hundreds of servers, software licenses, and a data center. You will need a fair amount of money every year to keep it running, right? So after a few years, you did some calculations and know exactly what is needed. Unfortunately, it is not that easy.

Another bad surprise

Even with rigorous budgeting effort, unwelcome surprises may show up in the mailbox of the manager. One of the best engineers might be leaving, or an internal department suddenly needs 10 systems to host their new application. Of course, something they didn’t share a month ago while talking with them. Whatever the surprise might be, it usually costs money. Money which was not part of the initial budget.

When you ask for a new tool, you might be actually part of this problem of surprises. If you want to make your manager happy and get more things arranged, be part of the solution, not the (budget) problem.

Budget cycle

Budget cycles are usually defined for a fixed period. This period mainly depends on how the company is structured. Some do it every quarter, others twice a year, or just once a year.It is common to see that the budget round finishes a few months before the

It is common to see that the budget round finishes a few months before the end of the year or the end of the financial year. Again, it depends on the company and how the financials are arranged. The budget cycle simple is adjusted. While this may be a simple fact, it is crucial for obtaining budget, as we will see later.

Buffers in budgets

To counter unexpected events, usually budgets are stretched beyond what is really needed. Also items which higher risk, like that unstable database cluster, might be included as a replacement cost. Besides the unexpected events, the manager may also include expected growth. If your server farm grows each year with 5%, you know that this won’t be equally divided over the year. So depending on the budget cycle, it may be better to ask more, than asking too little. This is especially true if the manager needs to explain for the 5th time why he has a budget overrun.

Obtaining budget

So you want to have a new tool in your daily activities, or as an extension of your toolkit. From previous experiences you get the “no budget” answer, or others tell you it won’t happen.

For the sake of providing an example, let’s use our tool Lynis. You discovered the free open source version, and totally got in love with it. After using it for a few months, you learn about the enterprise version and want to have that in your toolkit. To avoid the budget issue, you might ask yourself how to get around this. Let’s craft a budget plan!

Crafting the plan

Good plans are executed in steps. So let’s divide our master plan into 3 big steps:

  • Value
  • Timing
  • Proof

Step 1: Budget equals value

Budget is about money. Money is about trading. Trading is about exchanging value. So in other words, budget is about value. This also applies to software tools, open source, closed source, or the mix. In all cases, tools provide some level of value, but it may differ per user of the software.

Determine Personal Value

First step is to know what the value of the tool is for your organization. Don’t see it as another great toy, but really think about how it helps you in your daily work. Does it save you time? Does it remove tedious repeating steps?

Example: Lynis saves you time by automation. Checklists can be more often checked, and at the same time quicker and more reliable.

Determine Team Value

Then make it broader and see how the tool value relates to your manager and the team. Does it save money in the short or long term? Does it improve the quality of the IT environment? Does it make your team look more experienced?

Example: By using an auditing tool, we can reduce inconsistencies in our environment, which otherwise may lead to disruptions. We can find vulnerabilities which normally would stay undetected and may result in data disclosure.

Sell the Value

Keep in mind that you will have to “sell” the solution to your manager. This way he/she is able to reserve some budget for it. At the same time, the manager of the manager needs to be convinced as well. So if you write a proposal, don’t write it just in terms for your manager, but make it easy to forward. If you want a new tool, it is time to start selling!

Show by Example

One strong characteristic when selling your value proposition to your manager is providing examples. Show that you have done your diligence when searching for a solution. Explain how this solution can help. Don’t be afraid to show your weaknesses. We like to cover up things we discovered, in the hope that your manager never finds out. But it is better to show him you are doing a great job, but want to ensure there is an additional set of (cheap) eyes, testing it on a daily basis. From auditing tools up to vulnerability scanners, they help us to discover the things we simply couldn’t find ourselves, due to knowledge or time constraints.

Example: Currently we have to use custom built scripts to check if security patches are needed. This solution covers that. It goes much further, including checking other areas which are not part of our monitoring tooling. The free version already discovered 5 systems which had an outdated time server, something which is normally set during installation and not tested later on. With this tool we can more easily detect these and fix them, before they result in service disruption.

Use the Vendor

The vendor of a software solution knows the difficulties with budgets. As a founder, I’ve seen it myself. So tell in an early stage how your company deals with budgets. Also, ask if they can help with getting the value more clear to your company. Most of us techies are too careful to share details, thinking that the evil sales person may abuse this information.

While it is good to avoid sharing confidential data, giving insights on how your business operates, is valuable for both. It helps the vendor to understand your needs better and in some cases adjust the solution, to provide a better value for the money. Remember, it is all about the value and selling it internal.

Step 2: Choose the Right Moment

Even if have the best proposal ever, timing can be a nasty dealbreaker. So to counter this, you have to learn a little bit about the budgeting cycle of your company. This understanding may also help your manager. Tell him/her that you understand that budgeting can be challenging. Then ask what the soft and hard deadline is of the next cycle. The hard deadline is when everything has to be approved. However, it is the soft deadline which is interesting for you. That is the moment when your manager needs to submit his budget forecast.

Step 3: Show Proof That it Works

Knowing and selling the value of a solution is great. Perfect timing makes it even better. But the real winner is to lock the budget for the years to come. After all, you might need to pay a yearly fee. Other examples include upgrading the support contract to the next level, or simply the need for more licenses with a continuous growing server fleet.

Proof, Proof, and Proof

We all know that happy feeling when purchasing something new. But how often do we look back and consider the purchase to be a great investment? Even if you feel great with a particular software solution, you manager might think otherwise. To be sure your tool gets through another budget round, we need those gentle reminders that the solution is good. For that our first two steps come into play, again.

Repeat the Value

One method to show proof that a solution is working, is by using dashboard functionality. Show on a screen that everything is “green”, because you are using this tool. Optionally, use reports to show the discoveries your tool made. Even better is when it can show how it helped improving the quality of your environment. Maybe the amount of IT incidents dropped hugely, because of otherwise repeating issues.

Timing

Like the initial budget request, timing remains important. Your next budget requests will depend on them. Also when showing proof in the form of value to the company, timing can make a big difference. Ensure that it is done on a regular basis, so there is no doubt when another round of budget savings is announced.

Open source, Security and Money

Those who deal a lot with security in their job, are usually a lot of open source components. While free tools are great, we might perceive that security can be cheap by limiting ourselves to open source only. Even as an open source developer myself, I like to warn you about the bad consequences it may have for your company. For example when we look at the GNU/Linux kernel itself. Great that we can use it for free, but that is because of many commercial companies providing support, doing marketing and more importantly, submit patches. Most of the development and commits are nowadays done by big companies like Intel and Red Hat.

No Budget = Limited Growth

If you simply focus on cheap solutions, you will end up with limited resources. Open source, and especially free software, is great. But if you don’t have any budget to get a proper toolkit in place, you won’t get the maximum benefit out of your team.

People are Expensive, Tools are Not

Consider the cost of your company to hire you, every single month. Now multiply that by 12 and compare it with license of 1 single tool. Now is that 1200 euro/dollar really that much? Don’t think so!

Security is a Hard Sell

Security is a strange thing. Some people compare it with insurance. It is ok when you don’t have it. When something happens, then you wished you did have it. The biggest problem is explaining the value of a solution.

When looking at security products, have a look at how it helps reducing risks. Try to make it as tangible as possible. If you express something in a number, then do so. A great example is when you are using a CMDB and change/incident management tool. Have a quick look at the tickets in the last year and determine what happens often. It may provide a number on what kind of issues may be reduced, after implementing the new solution.

Example: by using an auditing tool we can measure how effective our policies are. We can then calculate the amount of systems being non-compliant and focus our time on the machines with missing security measures. Additionally, we can create reports for our customers, to help them deploying their applications more securely. In the last 6 months, we had at least 12 machines with a security breach, due to weak configurations, which otherwise would be detected up-front.

Practical tips

If you made it till the end of this blog post, it is time to receive an additional bonus. After all, speaking about value and timing, this is the spot to make it even better. Here are some practical tips which help to understand budgets and achieve your goals.

  • Learn from your manager about budgeting
  • Set a reminder in your agenda in advance of the budget cycle
  • Discuss with your team what tools are needed and make a top 3 sorted by value
  • Search or create an internal budget request template, to know what information is needed for approval
  • Involve your manager, and get easier buy-in for the new purchase
  • Make use of the vendor to supply enough information, and reduce purchasing risks

Got more tips for others who struggle to get budget? Go for it in the comments.


Enjoyed reading the article? Share your discovery with others:
twittergoogle_plusreddit

Kernel hardening: Disable and blacklist Linux modules

Kernel Hardening

Disable and blacklisting and Linux modules

The Linux kernel is modular, which makes it more flexible than monolithic kernels. New functionality can be easily added to a run kernel, by loading the related module. However, in some cases you don’t want this flexibility to be abused. Think about loading of malicious modules, or unauthorized access to the server and copy data via an USB port. In our previous article about kernel modules, we looked at how to prevent loading any module. In this case, we specifically disallow the ones we don’t want.

Blacklisting Linux modules

One option to disallow loading modules, is by blacklisting them. This defines the modules which the kernel should no longer load. However, there is an important addition to make, as this is only limit the loading during the boot process. You can still load a module afterwards.

Blacklisting a module is simple. Create a file in the /etc/modprobe.d directory and give it a related name (e.g. blacklist-module.conf).

Blacklisting firewire

Let’s say we want to blacklist firewire. We first have to determine what modules are available. By using find, we can quickly determine the related kernel drivers:

[root@arch kernel]# find /lib/modules/`uname -r` -name *firewire*
/lib/modules/4.0.1-1-ARCH/kernel/drivers/firewire
/lib/modules/4.0.1-1-ARCH/kernel/drivers/firewire/firewire-ohci.ko.gz
/lib/modules/4.0.1-1-ARCH/kernel/drivers/firewire/firewire-core.ko.gz
/lib/modules/4.0.1-1-ARCH/kernel/drivers/firewire/firewire-sbp2.ko.gz
/lib/modules/4.0.1-1-ARCH/kernel/drivers/firewire/firewire-net.ko.gz
/lib/modules/4.0.1-1-ARCH/kernel/drivers/media/firewire
/lib/modules/4.0.1-1-ARCH/kernel/drivers/staging/fwserial/firewire-serial.ko.gz
/lib/modules/4.0.1-1-ARCH/kernel/sound/firewire
/lib/modules/4.0.1-1-ARCH/kernel/sound/firewire/snd-firewire-lib.ko.gz

Now we know there are multiple modules, most part of the drivers and one in the sound section. If we want to disable all these modules, we could simply blacklist them all. Or block the generic category.

Gathering module information

By using modinfo, we can gather the details about a particular module. In this case we have a look at the snd-firewire-lib and see what it does:

Screenshot of modinfo which shows a dependency

modinfo shows on which a module depends

We can see it depends on firewire-core. Let’s have a look at the firewire-core module itself:

Screenshot of modinfo of firewire core module

Details of firewire core module

The details of the firewire-core module show that is responsible for firewire itself. It is the core unit itself and doing the transaction logic within the IEEE1394 protocol specifications. We can see it is depending on the CRC-ITU-T standard.

By disabling the firewire-core, we effectively disable any module depending in it. In this case we don’t blacklist the crc-itu-t module, to prevent other modules from properly functioning.

The related snippet to blacklist would be:

/etc/modprobe.d/blacklist-firewire.conf

blacklist firewire-core

See blacklisted modules

To see what modules are currently blacklisted, we can use the modprobe command:

[root@arch kernel]# modprobe --showconfig | grep blacklist
blacklist firewire_core

This will show all modules which are blacklisted.

Disable modules

The next level of blacklisting modules, is actually to disable them. This way they won’t be loaded unintentionally.

To disable a module, we have to redirect a module via the install option. This instructs the modprobe command to use a specific file. By redirecting it to /bin/true or /bin/false, it won’t be loaded.

Screenshot of modprobe failing

Using the install option we can avoid loading modules

Tip: Using /bin/false as install target is better, as it clearly shows in the configuration that something is not allowed.

To see what modules are currently disabled via install, we can use modprobe as well:

[root@arch kernel]# modprobe --showconfig | grep "^install" | grep "/bin"
install firewire_core /bin/false
install firewire_ohci /bin/false

Note: the root user can still override settings, by using the –ignore-install parameter. So in that case the module can still be loaded, if required.

Instead of using the install routine, also the alias option could be used. This can redirect a module to /dev/null for example.

Conclusion

By using the right combination of blacklist, install and alias, we can disallow the loading of Linux kernel modules. They form the first level of defense against uninentional and unauthorized module loading. By using the kernel setting kernel.modules_disabled and set its value to 1, we can make sure things are really tightened. Even the root user can not load any modules anymore.

Useful commands

 

  • Blacklisted and disabled modules
    • modprobe –showconfig | egrep “^(blacklist|install)”
  • Find modules
    • find /lib/modules/`uname -r -print
  • Load module
    • modprobe module
  • Unload module
    • modprobe -r module
  • Module details
    • modinfo module

Enjoyed reading the article? Share your discovery with others:
twittergoogle_plusreddit

Increase kernel integrity with disabled Linux kernel modules loading

Increasing Linux kernel integrity

Disable loading kernel module on Linux systems

The Linux kernel can be configured to disallow loading new kernel modules. This feature is especially useful for high secure systems, or if you care about securing your system to the fullest. In this article, we will have a look at the configuration of this option. At the same time allowing legitimate kernel modules to be loaded.

Disable kernel modules

Newer kernel modules have a sysctl variable named kernel.modules_disabled.

Sysctl is the tool which allows you to see and change kernel settings of a running system. The related /etc/sysctl.conf file is used to ensure that your settings are also used at the next boot of the system.

The sysctl key kernel.modules_disabled is very straightforward. If it contains a “1” it will disable loading new modules, where a “0” will still allow loading them.

Using this option will be a great protection against loading malicious kernel modules. For example, it may help to counter rootkits. Needless to say, but when someone was already been able to gain root access, you have a serious problem. Still, setting this security measure can be useful to achieve maximum hardening of your Linux system. An altered script or program has no chance of loading things you didn’t specifically approve.

Loading modules

To show this functionality, we first will load a module and then see how the related sysctl value works. For this demo purpose, we will use the XOR module, which is part of the crypto category.

# cd /lib/modules/3.13.0-24-generic/kernel/crypto/
# ls -l
total 1012
-rw-r--r-- 1 root root  8516 may 3 2014 ablk_helper.ko
-rw-r--r-- 1 root root 20436 may 3 2014 af_alg.ko
-rw-r--r-- 1 root root 13892 may 3 2014 algif_hash.ko
-rw-r--r-- 1 root root 17748 may 3 2014 algif_skcipher.ko
-rw-r--r-- 1 root root 11772 may 3 2014 ansi_cprng.ko
-rw-r--r-- 1 root root 15756 may 3 2014 anubis.ko
-rw-r--r-- 1 root root  6828 may 3 2014 arc4.ko
-rw-r--r-- 1 root root 17180 may 3 2014 authencesn.ko
..snip..
-rw-r--r-- 1 root root 26076 may 3 2014 twofish_common.ko
-rw-r--r-- 1 root root 10028 may 3 2014 twofish_generic.ko
-rw-r--r-- 1 root root 13540 may 3 2014 vmac.ko
-rw-r--r-- 1 root root 31372 may 3 2014 wp512.ko
-rw-r--r-- 1 root root  9028 may 3 2014 xcbc.ko
-rw-r--r-- 1 root root 21124 may 3 2014 xor.ko
-rw-r--r-- 1 root root 10596 may 3 2014 xts.ko
-rw-r--r-- 1 root root 16396 may 3 2014 zlib.ko

Background information:

The XOR kernel module uses the “exclusive OR” function, which returns True when an odd number of the given arguments equals to be true, and False when an even are true. Usually it is used with two arguments, so to return True, only 1 of the options can be positive.

Back to the loading of the module. First we ensure this module is not loaded:

# lsmod | grep xor

Now we load the module with the insmod command and then check if loading was successful:

# insmod xor.ko
# lsmod | grep xor
xor 21411 0

The module is loaded, as expected. To show normal behavior, we now will remove the kernel module with the rmmod command.

# rmmod xor
# lsmod | grep xor

The module is released. Time to disable this functionality, to increase protection against loading malicious modules.

Activating kernel.modules_disabled

By default, the sysctl key is set to “0”, which means new modules can be loaded. This is a safe default for systems but also allows malicious modules to be loaded.

# sysctl -a | grep modules
kernel.modules_disabled = 0

Now we disable loading new modules, by using the sysctl key and set it to “1”. There are two ways of doing it, using sysctl directly or echo the value to a file on the pseudo file system /proc, which holds the kernel settings.

# echo 1 > /proc/sys/kernel/modules_disabled

Now we try loading our XOR module again:

# insmod xor.ko
insmod: ERROR: could not insert module xor.ko: Operation not permitted

Loading the module is now no longer allowed, exactly what we wanted.

Protection against re-enabling

You might think that loading a kernel module is as simple as re-enabling the option and then still load your kernel module. The kernel has a built-in protection, to avoid this from happening. Trying to set the value back to “0” will result in an “invalid argument” message.

Sysctl showing invalid argument when trying to set value

Sysctl showing invalid argument when trying to set value

As can be seen, sysctl will say the value is set to “0”. However, the value isn’t applied, as this key is read-only. Slightly confusing, and therefore always good to check the value again.

# sysctl kernel.modules_disabled
kernel.modules_disabled = 1

As expected, the value is still set to “1”.

Disable module loading after boot time

By configuring the /etc/sysctl.conf file we can disallow the loading of kernel modules at boot time. Simply add the related line, with the value “1” as shown in the example.

Caveat: Things might break

Depending on your environment, you might be careful with using this option. It may be working very well on servers, but not on desktop systems. The reason is the type of usage is different, especially when it comes with loading new kernel modules. For example inserting a USB drive, mouse or network functionality might break. So before deploying the option, make sure you test these common use cases.

Hybrid option

Instead of enabling the option directly via /etc/sysctl.conf, it might be better to activate this setting after booting and loading required modules.

Your startup script could be looking like:

#!/bin/sh/
sleep 300
insmod <module>
echo 1 > /proc/sys/kernel/modules_disabled

 

Do you use this option already? Or found some other caveats? Like to hear your feedback in the comments.


Enjoyed reading the article? Share your discovery with others:
twittergoogle_plusreddit

« Older Entries