His perspective was that it adds an extra step before login, so is bad from a usability perspective, so there must be a reason.

This got a lot of attention, but looking at the top answers:

Adnan‘s answer briefly describes the Secure Attention Key – the Windows kernel will only notify the Winlogon process about this key combination, which prevents it being hijacked by an application, malware or some other process.  In this way, when you press Ctrl+Alt+Del, you can be sure that you’re typing your password in the real login form and not some other fake process trying to steal your password. For example, an application which looks exactly like the windows login. An equivalent of this in Linux is Ctrl+Alt+Pause

Polynomial‘s comment on the answer further expands on the history of this notification:

As a side note: when you say it’s “wired”, what that actually means is that Ctrl+Alt+Del is a mapped to a hardware defined interrupt (set in the APIC, a physical chip on your motherboard). The interrupt was, historically, triggered by the BIOS’ keyboard handler routine, but these days it’s less clear cut. The interrupt is mapped to an ISR which is executed at ring0, which triggers the OS’s internal handler for the event. When no ISR for the interrupt is set, it (usually) causes an ACPI power-cycle event, also known as a hard reboot.

ThomasPornin describes an attack which would work if the Secure Attention Key didn’t exist:

You could make an application which goes full-screen, grabs the keyboard, and displays something which looks like the normal login screen, down to the last pixel. You then log on the machine, launch the application, and go away until some unsuspecting victim finds the machine, tries to log on, and gives his username and password to your application. Your application then just has to simulate a blue screen of death, or maybe to actually log the user on, to complete the illusion.

There is also an excellent answer over on ServerFault, which TerryChia linked to in his answer:

The Windows (NT) kernel is designed to reserve the notification of this key combination to a single process: Winlogon. So, as long as the Windows installation itself is working as it should – no third party application can respond to this key combination (if it could, it could present a fake logon window and keylog your password

So there you have it – as long as your OS hasn’t been hacked, CTRL+ALT+DEL protects you.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

Refreshing DNS

A short refreshment of the DNS protocol. We have different types of DNS servers, namely:

• Authoritative Nameservers
• Resolving/caching Nameservers

The authoritative nameserver is the nameserver which is responsible for a/multiple domain(s). These DNS servers know the correct IP address that belongs to one of his domains. If you need to know the IP that belongs to example.com. The responsible DNS server for example.com will have to be consulted to know the actual IP.

The resolving nameserver is a nameserver to whom clients can ask to resolve a certain domain. For instance if the client needs to know the IP of example.com it will ask the resolving nameserver, the resolving nameserver will then ask to the authorative nameserver (or a DNS server which can point him to what DNS server might know) what IP belongs to example.com. To put a little simplistic here’s an example:

• Computer: I need to know the IP of example.com, I shall query the configured Resolving DNS server A
• DNS server A: Computer needs to resolve example.com, I don’t know example.com, but I know who knows .com, I’ll ask DNS Server B
• DNS server B: I don’t know the IP of example.com, but I know the server who is responsible for example.com, it’s DNS Server C
• DNS server A: Hello DNS server C, what is the IP of example.com?
• DNS server C: Hello DNS server A, I know the IP for example.com, it’s 1.2.3.4
• DNS server A: Hello computer, the IP address of example.com is 1.2.3.4

In principle a resolving DNS server should only respond to hosts he trusts. For instance as an ISP you want all requests comming from clients using IPs allocated or used by you to be able perform DNS requests, but not outside of your network. However this is where things go wrong, some resolving DNS servers are completely open and will reply to anyone who asks. This is handy in one way, because if you ever need to resolve domain names and the network you are in doesn’t have a DNS server, you can just ask any of the open ones. I always make my machines resolve from 8.8.8.8, which is Google’s DNS service. It’s an easy to remember number and you know the reliability will probably be alot higher than your ISP can guarantee.

Another feature of DNS which facilitates this attack is contained in the 4th layer of the OSI model, the transport layer. DNS is sent over UDP (it can actually also be sent over TCP according to the RFC, but it’s not used a lot), UDP is a connection-less protocol meaning it provides no consistency or reliability that you received all data, but at the same time the amount of overhead is reduced, making it very fast. The light weightness and speed of UDP makes it ideal for DNS, in the end you just want a chunk of a relatively small amount of data. Because it doesn’t require a handshake to be completed, you can easily spoof the source IP of the UDP request and the server will answer to whatever source IP you put in the UDP request.

Amplification: a flaw in the DNS protocol

Do note that the following examples are in an ideal world and would possibly not be achievable. As said before you can request a DNS server to give you a corresponding IP for a certain domain name you would like to resolve. A major flaw in DNS is the size of the question versus that of the answer. On average a DNS request is about 20-30 bytes long, but answers (depending on what you ask) can go up to 512 bytes. This is where things become interesting, because this means that a server replying to a DNS message needs to send significantly more data than the original requestor did. This was actually used in the past to take down DNS servers as they need to perform a lot more effort than the requestor.

Since we can alter the source address of the DNS request, we can put the our victim’s IP address as source. We then send a valid DNS request with the modified source address to a resolving DNS server. It will then send the answer to the address located in the DNS request. Let’s say we have a 1 Mbit line (upload) and we saturate it completely with 25 byte long requests, we should (ideally) be able to send 5000 requests per second. Because we have altered the DNS request source address it’s our victim that will receive all the answers. Since the requests are up to 512 bytes long, this might result in 5000*512 bytes/s (2.4 megabyte) or almost 20 Mbit/s. This is why it’s called a DNS amplification attack, because we can transform our 1 mbit into 20 mbit, amplifying the traffic.

There are a lot of benefits for using this type of Denial of Service, because you can use “slow” lines. The upload speed needn’t be massive to generate a lot of traffic, so ADSL lines used in internet home connections can be used more effectively. You also don’t need a lot of compromised machines. To get the same amount of traffic by just doing a normal UDP flood, you would need 20 times (the amount of amplification) more hosts. Discovering these bots will be difficult as well since the source address is altered.

Now in the case of Spamhaus, an attack was initiated with a bandwidth reaching up to 300 gbit/s. There were some claims about the DDoS being “the one that almost broke the internet“, however a Tier one provider (NTT) said that while 300 gbit/s may be a lot of bandwidth for a single enterprise, but considering Tier 1 providers are running into several tbit/s, 300 gbit isn’t going to take them down so easily. Akamai said that they didn’t see the internet taking a big hit, just a rather high increase of traffic around Western Europe (as displayed in the figure below).

This doesn’t mean it wasn’t significant, Kaspersky Labs said that it is probably the largest DDoS ever recorded. Eugene Kaspersky even said we have to be happy they only used 30 thousand resolvers. This attack could have taken down a lot of DNS servers as well, which may end in disturbing service. The fear mongering is obviously a marketing technique used by CloudFlare to gain more clients, but regardless of their marketing stunts, I must admit they still did a great job at mitigating attack. PALMAM QUI MERUIT FERAT, “let whoever earns the palm bear it”, not only CloudFlare helped Spamhaus to mitigate this attack, but also Google absorbed some of the traffic.

Who ever initiated the attack is still unclear, but a lot of people seem to think it was the recent mass-blocking of all CyberBunker clients. Investigations are still pending.

Mitigation

How was this mitigated? Well first have a read of Thomas Pornin’s answer. In this case, instead of calling the firemen, they actually decided no-one can access Jim’s shop directly, instead people can come in through different gates, there are a lot of gates available and at every gate there is a guard, verifying why the person came to Jim’s shop. Now the guard will check if someone is telling the shopkeeper he’s from Germany, but coming from a road originating from France, chances are he’s from France and not really from Germany, so there must be something wrong and he shouldn’t be let into Jim’s shop.

In practice this was done with the anycast protocol. Anycast is used to route traffic to the nearest node, depending on your geographical location this will be a different machine/network for a different location. Google uses this as well for their DNS services. So anycast is “one IP, multiple machines“.

Because the attackers were sending requests from different locations, this resulted in the traffic being divided between the 24 datacenters CloudFare owns. This means 12.5 gbit per datacenter, which is a lot more manageable for one datacenter. Also note that routers route an amount of packets, vendors often say they can route 10 or 24 gbit/s, but actually this is calculated as a certain amount of packets with a certain size. Because the packet-size is quite high the router can cope with this type of attack relatively well (the 12.5 gbit/s is comprised of 300-500 byte packets).

Countermeasures

Now what can you do against a DNS Amplification attack? First of all everyone should secure their DNS servers, only allow certain hosts to do DNS requests. Now open recursive DNS servers aren’t actually the only ones to blame. The actual problem is the possibility of IP spoofing, so to counter that BCP38 was defined. BCP38 describes ingres filtering, making “sure that incoming packets are actually from the networks that they claim to be from“.

BCP38 defines that if a packet with a certain IP is coming from a segment within your LAN which is actually impossible to be there, drop it. For instance if you manage a subnet 80.10.10.0/16 and suddenly you see a packet flying by with source IP 193.10.10.1 you know something is fishy because there is no way that 193.10.10.1 is legitimately located within that LAN segment (we can also look at complete regions rather than subnets) under your control and therefore it should be dropped rather than forwarded. In short:

IF packet's source address from within [its assigned space]
THEN forward as appropriate
IF packet's source address is anything else
THEN deny packet

BCP38 has been around for 13 years. So it’s about time that everyone adopts (already 80% of the internet is!) it as it will mitigate a lot of attacks involving IP spoofing.

Conclusion

To wrap it up:

• DNS uses UDP which allows the source IP address to be spoofed easily
• 300 gbit/s didn’t actually pose a threat to the internet
• 300 gbit/s is however, probably the biggest DDoS we have ever seen
• DNS Amplification is caused by open DNS resolvers, but the open resolver is not the only problem
• Some providers aren’t even aware they are open resolvers
• DNS Amplification is caused because a lot of people have not adopted BCP38

If you have comments, questions or think I’m wrong, I’m always open to constructive criticism, so feel free to contact me or leave a comment below.

In fact, our top meta meme explains why – the First Rule of Crypto is “Don’t Roll Your Own!”

So, with that in mind, Polynomial’s answer, delivered with a liberal dose of snark, explains in simple language:

This home-brew method offers no real resistance against brute force attacks, and gives a false impression of “complicated” security…Stick to tried and tested key derivation algorithms like PBKDF2 or bcrypt, which have undergone years of in-depth analysis and scrutiny from a wide range of professional and hobbyist cryptographers.

Konerak lists out some advantages of going with an existing public protocol:

• Probably written by smarter people than you
• Tested by a lot more people (probably some of them smarter than you)
• Reviewed by a lot more people (probably some of them smarter than you), often has mathematical proof
• Improved by a lot more people (probably some of them smarter than you)
• At the moment just one of those thousands of people finds a flaw, a lot of people start fixing it

KeithS also gives more detail:

• MD5 is completely broken
• SHA-1 is considered vulnerable
• More hashes don’t necessarily mean better hashing
• Passwords are inherently low-entropy
• This scheme is not adding any significant proof of work

Along with further answers, the discussion on this post covered a wide range of issues – well worth reading the whole thing!

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

Securi-Tay is an annual security conference organised by students at Abertay and is a very well organised and run event – could put some professional conferences to shame!

Video of my talk

The talk went down very well, with a lot of discussion spinning off afterwards, and the odd additional visitor to Sec.SE

Most of the video should be straightforward, but a couple of the slides may be hard to read so I have included them here:

Slide 8, industry trends:

Slide 13, some useful certifications:

Slide 14, the time-bounded nature of certifications:

Slide 16, self marketing (see that nice big Sec.SE logo:-):

The show the variety of aspects security covers in this sort of scenario:

Daniel posted the top answer, and it has nothing to do with IT, but instead focuses on the cause – if a user has installed an access point it is because they need something the existing network is not providing. This is always worth considering:

Discuss with the users what they are trying to accomplish. Perhaps create an official wifi network ( use all the security methods you wish – it will be ‘yours’ ). Or, better, two – Guest and Corporate WAPs.

Polynomial and Thomas Pornin also highlighted the fact this is a user/managerial problem, rather than a technical one.

Remember Immutable Law of Security #10: Technology is not a panacea. Whilst technology can do some amazing things, it can’t enforce user behaviour. You have a user that is bringing undue risk to the organisation, and that risk needs to be dealt with. The solution to your problem is _policy_, not technology. Set up a security policy that details explicitly disallowed behaviours, and have your users sign it. If they violate that policy, you can go to your superiors with evidence of the violation and a penalty can be enforced. As long as the users have physical access to the machines they use and their USB ports (that’s hard to avoid, unless you pour glue in all the USB ports…) and that the installed operating systems allow it (then again, hard to avoid if users are “administrators” on their systems, in particular in BYOD contexts), then the users can setup custom access points which gives access to, at least, their machine.

Rory McCune provided some information on the types of solutions which generally are used in large corporates, where they work well, including NAC and port lockdowns. Lie Ryan‘s comments tend to be appropriate on smaller networks.

k1DBLITZ also focuses on the use of technical solutions in addition to policy, and JasperWallace recommends looking for and blocking unapproved MAC addresses, and further answers discuss wireless scanning and scripted checks.

Overall, it would seem that a mixture of technical and management controls are required – the balance depending on your specific environment.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

Ignoring the obvious innuendos in the comments, I think this is an excellent question. While the question is far longer, this is the gist of it.

As ITSec pros, we talk about infusing the development cycle with secure coding practices and design, but how does that apply to a brand-new learner? A new programmer is at the start of their own ‘lifelong development cycle’, at it were. At what point is it appropriate, from an educational perspective, to switch from the mindset of ‘getting it to work’ to ‘it absolutely must be secure’? At what point should a student ‘fail’ an assignment because of a security issue?

As a student in an infosec diploma course, I have rather strong opinions on this matter. Let’s start with a personal anecdote. I personally started learning programming on my own due to self-interest. My first exposure to “real” programming is through PHP(I know… shudders). Do a quick google search using the terms “php tutorial”. Go on. The very first link points towards w3schools.com.

A quick browse through the site looks good. Nice, simple, easy to follow tutorials on the basics of PHP and HTML. Wait, are they really teaching unparameterized queries? In 2013? Really? I’d like to point you to this website. In particular, this quote.

W3Schools.com is not affiliated with the W3C in any way. Members of the W3C have asked W3Schools to explicitly disavow any connection in the past, and they have refused to do so. W3Schools frequently publishes inaccurate or misleading content. We have collected several examples illustrating this problem below.

This is an obvious problem. A website on the top of Google’s search results targeted at new programmers providing misleading information? What could go wrong right?

Moving on to the actual question.

User Everett stated this in his answer.

The problem I see, is that secure programming is taught as an add on. Best practices should be taught from the beginning (including security). The lie people are taught is that practice makes perfect. The truth is practice makes permanent. So if you are doing it wrong, you have to unlearn what you have learned. That is a bassackwards approach. I would say that secure coding practices should be taught from day one. There’s no reason to learn how to do it, and then learn how to do it securely. It’s a waste of time and money…

I disagree with his opinion. I think user KeithS provides a very good point.

It’s great to say “Secure coding practices should be taught from day one”, and very hard to demonstrate how that day-one “Hello World” program may be vulnerable, especially when “what is a computer program” is a new concept for the class.

I agree. Many of my peers who entered the diploma course without any prior programming experiences have a tough time even wrapping their heads around basic concepts like looping and conditional statements. Introducing more complex security topics at this point in their education would more likely cause more harm than good.

This is the answer I provided to the question.

I would say a great way to learn is for her to break the applications she has already written. Assuming she is writing web applications, point her towards the OWASP Top 10. Have her see if she can find any of those flaws in her own code. There is no better way to learn about security concepts than actually seeing it happen on your own code. Once a flaw has been found, have her rewrite the application to fix the flaw. Doing so will allow her to appreciate the effect of things like sanitation and validation of user inputs and parameterized queries. Take incremental steps. I wouldn’t jump straight into designing a new application with security in mind before truly understanding what type of codes result in security flaws.

With 37 upvotes and the answer being accepted, it is clear that the community agrees with me.

Conclusion

I think the best approach to teaching secure programming is an iterative one. Start off the students with writing simple applications. Have the students go back and look at their code and see how it can be broken. Refer them to good resources like the OWASP Top 10 list. With a little critical thinking, the students should be able to start figuring out what went wrong in their code and how to fix it.

Like user AviD said,

Students that do not practice critical thinking shouldn’t really be learning programming….

This post is a cross-post from my blog at http://www.infosecstudent.com/2013/02/teaching-secure-programming-how-to-do-it-right/

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

Saber asked this question because he had come across various websites designed to let people share their network diagrams and designs in order that others can comment on them and provide guidance and he wondered what the risks would be from this.

As an example, this diagram from www.ratemynetworkdiagram.com provides IP addresses, host names and even descriptions:

AJ Henderson provided the very valid comment that security through obscurity is not security, but admits that any network will have some weaknesses, and avoiding giving this information to a potential attacker is probably advised.

My answer is taken from the experience of managing many hundreds of penetration tests. My take on it is:

having a map helps me target my attack, avoiding possible sensors, honeypots etc and aiming at high value targets or sources of information. This can speed up an attack immensely, reducing the defender’s chance of preventing it.

But the value from these sites is that you can have obvious mistakes pointed out to you – peer review can be a very valuable thing. So how can you do that safely?

To reduce risk, some steps you can take are:

• remove addresses, function titles etc
• only include sections of the network
• post under an anonymous profile
• include fake network sections

An attacker will still get information, but it hopefully won’t be enough to let them navigate your entire network.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

All in all, it is a pretty fantastic tool for monitoring what’s happening on your system. Since it operates at the kernel level this gives us a hook into any system operation we want. We have the option to write a log any time a particular system call happens, whether that be unlink or getpid. We can monitor access to any file, all network traffic, really anything we want. The level of detail is pretty phenomenal and, since it operates at such a low level, the granularity of information is incredibly useful.

The biggest downfall is actually a result of the design that makes it so handy. This is itself a logging system and as a result does not use syslog. The good thing here is that it doesn’t have to rely on anything external to operate, so a typo in your (syslog|rsyslog|syslog-ng).conf file won’t result in losing your system audit logs. As a result you’ll have to manage all the audit logging using the auditd suite of tools. This means any kind of log collection, organization, or archiving may not work with these files, including remote logging. As an aside, auditd does have provisions for remote logging, however they are not as trivial as we’ve come to expect from syslog.

Thanks to the level of integration that it provides your auditd configurations can be quite complex, but I’ve found that there are primarily only two options you need to know.

1. -a exit,always -S <syscall>
2. -w <filename>

The first of these generates a log whenever the listed syslog exits, and whenever the listed file is modified. Seems pretty easy right? It certainly can be, but it does require some investigation into what system calls interest you, particularly if you’re not familiar with OS programming or POSIX. Fortunately for us there are some standards that give us some guidance on what to look out for. Let’s take, for example, the Center for Internet Security Red Hat Enterprise Linux 6 Benchmark. The relevant section is “5.2 Configure System Account (auditd)” starting on page 99. There is a large number of interesting examples listed, but for our purposes we’ll whittle those down to a more minimal and assume your /etc/audit/audit.rules looks like this.

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.
# First rule - delete all
-D


# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024
-a always,exit -S adjtimex -S settimeofday -S stime -k time-change
-a always,exit -S clock_settime -k time-change
-a always,exit -S sethostname -S setdomainname -k system-locale
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k identity
-w /var/run/utmp -p wa -k session
-w /var/log/wtmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /etc/selinux/ -p wa -k MAC-policy
# Disable adding any additional rules - note that adding new rules will require a reboot
-e 2

We’re also watching a few files. The first four (group, passwd, shadow, sudo) will let us know whenever users get added, modified, or privileges changed. The next three files (utmp, wtmp, btmp) store the current login state of each user, login/logout history, and failed login attempts respectively. So monitoring these will let us know any time an account is used, or failed login attempt, or more specifically whenever these files get changed which will include malicious covering of tracks. Lastly, we’re watching the directory ‘/etc/selinux/’. Directories are a special case in that this will cause the system to recursively monitor the files in that directory. There is a special caveat that you cannot watch ‘/’.

When watching files we also added the option ‘-p wa’. This tells auditd to only watch for (w)rites or (a)ttribute changes. It should be noted that for write (and read for that matter) we aren’t actually logging on those system calls. Instead we’re logging on ‘open’ if the appropriate flags are set.

It should also be said that the logs are also rather…complete. As an example I added the system call rule for sethostname to a Fedora 17 system, with audit version 2.2.1. This is the resultant log from running “hostname audit-test.home.private” as root.

type=SYSCALL msg=audit(1358306046.744:260): arch=c000003e syscall=170 success=yes exit=0 a0=2025010 a1=17 a2=7 a3=18 items=0 ppid=23922 pid=26742 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=16 comm="hostname" exe="/usr/bin/hostname" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="system-locale"

Next we see that the command was run by root, since the euid is 0. Interestingly, the field auid (called audit uid) contains 1000, which is the uid of my regular user account on that host. The auid field actually contains the user id of the original logged in user for this login session. This means, that even though I used “su -” to gain a root shell the auditing subsystem still knows who I am. Using su to gain a root shell has always been the bane of account auditing, but the auditd system records information to usefully identify a user. It does not forgive the lack of command line options, but certainly makes me feel better about it.

These examples, while handy, are also only the tip of the iceberg. One would be hard pressed to find a way to get more detailed audit logging than is available here. To help make our way down the rabbit hole of auditd let’s turn this into a series. We’ll collect ideas for use cases and work up an audit config to meet the requirements, much like what I ended up doing on this security.stackexchange.com answer.

If this sounds like fun let me know in the comments and I’ll work up a way to collect the information. Until then…Happy Auditing!

I saw some excellent speakers, and gave a talk on career planning in information security, so mine was by far the least technical talk there.

Highlights for me:

• Rory McCune gave an excellent talk on automation of security testing, both as a standard practice to make life easier, but to help consistency and standards in testing.

• Marion McCune presented on using the Windows Surface for security testing, which I think surprised everyone with the power of an ARM powered tablet.

• Graham Sutherland’s talk on attacking office hardware ranged from simple and relatively harmless, to pretty hardcore hacking via chip removal and analysis. Excellent fun, but sadly there was no party hat…

• Nick Walker’s talk on Android Security Assessments, while slightly too technical for me, was very interesting, and reminded me to pop Cyanogenmod on my Galaxy S3 this weekend.

• The” Rory track” – of the two lecture theatres, one had 3 Rorys presenting, which just goes to confirm one of the Memes of Meta…

And the good folks at Securi-Tay kindly donated this bright red t-shirt to my con swag collection, so I went home even happier!

It’s common knowledge that if somebody has physical access to your machine they can do whatever they want with it, so what is the point?

This one attracted a lot of views, as it is a simple question of interest to everyone.

Both Bruce Ediger and Polynomial answered with the core reason – it removes the risk from the casual attacker while costing the user next to nothing! This is an essential factor in cost/usability tradeoffs for security. From Bruce:

The value of locking is somewhat larger than the price of locking it. Sort of like how in good neighborhoods, you don’t need to lock your front door. In most neighborhoods, you do lock your front door, but anyone with a hammer, a large rock or a brick could get in through the windows.

and from Polynomial:

An attacker with a short window of opportunity (e.g. whilst you’re out getting coffee) must be prevented at minimum cost to you as a user, in such a way that makes it non-trivial to bypass under tight time constraints.

Kaz pointed out another essential point, traceability:

If you don’t lock, it is easy for someone to poke around inside your session in such a way that you will not notice it when you return to your machine.

And zzzzBov added this in a comment:

…few bystanders would question someone walking up to a house and entering through the front door. The assumption is that the person entering it has a reason to. If a bystander watches someone break into a window, they’re much more likely to call the authorities. This is analogous with sitting down at a computer that’s unlocked, vs physically hacking into the system after crawling under a desk.

It removes a large percentage of possible attacks – those from your co-workers wanting to mess with your stuff – thanks enedene.

So – protect yourself from co-workers, casual snooping and pilfering and other mischief by simply locking your machine every time you leave your desk!

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.