In a classic move, clearly designed to introduce National Cyber Security Awareness Month with quite a bang, the US Government has shut down, making it questionable as to whether National Cyber Security Awareness Month will actually happen.
In case the DHS isn’t able to make things happen without funding, here’s what they originally had planned:
I’m sure you’ll find myself and a few others keen to engage you on Information Security this month in the absence of any functioning legislators.
Maybe without the government in charge, we can stop using the “C” word to describe it.
The “C” word I’m referring to is, of course, “Cyber”. Bad word. Doesn’t mean anything remotely like what people using it think it means.
The main page of the DHS.GOV web site actually does carry a small banner indicating that there’s no activity happening at the web site today.
So, there may be many NCSAM events, but DHS will not be a part of them.
I admit that it’s a little strange to look at your event log fairly often, but I occasionally find interesting behaviour there, and certainly whenever I encounter an unexpected error, that’s where I look first.
Because that’s actually where developers put information relating to problems you’re experiencing.
So, when I tried to install Windows 8.1 and was told that I would be able to keep “Nothing” – no apps, no settings, etc – I assumed there would be an error in the log.
But all I saw was this:
So, yes, that’s an error with:
Event ID: 16385
Error Code: 0x80041316
This goes back to September 2, but only because the Application log that it’s in has already run out of room and ‘rolled over’ with too many entries. Presumably, then, the occurrence that caused this was prior to that.
Searching online, I find that there are some others who have experienced the same thing, the most recent of which is in January 2013, and who posted of this error to the TechNet forums.
A Microsoft representative had answered indicating that the cause could be (of all strange things) a partition with no name. Odd. Then they suggested Refreshing or Reinstalling the PC.
I’m not reinstalling unless there’s something hugely wrong, and the refresh didn’t help at all.
So, on to tracing the cause of the problem.
“Schedule” suggests it might be a Task Scheduler issue, and sure enough, when I open up the Task Scheduler (it’s under the Administrative Tools in the Control Panel, so making it very hard to find in Windows 8), I get the following error:
Or for the search engines to find, title: “Task Scheduler”, text: “Task SvcRestartTask: The task XML contains an unexpected node.”
It’s a matter of fairly simple searching (as an Administrator, naturally) to find this file “SvcRestartTask” under C:\Windows\System32\Tasks\Microsoft\Windows\SoftwareProtectionPlatform.
So I moved this file to a document SvcRestartTask.xml in a different folder.
Time to edit it.
Among other lines in the file, these stood out:
Odd – two values for Priority, one numeric, one text. So I went hunting in a file from a system that didn’t have that problem. I found these lines in the same place:
So, clearly something had written to the SvcRestartTask file with incorrect names for these elements. Changing them around in my XML version of the file, I reopened the Task Scheduler UI, navigated down to Microsoft / Windows / SoftwareProtectionPlatform, and imported the XML file there. [This is under “Actions”, but you can also right-click the folder SoftwareProtectionPlatform and select “Import”, then “Refresh”]
Sadly, this wasn’t quite the end of things, because the Task Scheduler UI fails to talk to the Task Scheduler service. Nor can I restart the Task Scheduler service directly.
So a restart will take care of that, and sure enough, now that I’ve restarted, I see no more of these 16385 errors from Security-SPP.
It’s just a shame it took so long to get this answer, and that the Microsoft-supplied answer in the forums is incomplete.
Oh, and of course, one last thing – what does SPP (Software Protection Platform) actually do?
Since this is an element of the Windows Genuine Advantage initiative, with the goal of preventing use of pirated copies of Windows, you might consider you don’t really need / want it around. Either way, you definitely don’t want it clearing your Application event log out every three weeks!
I’ve done an amount of training developers recently, and it seems like there are a number of different kinds of responses to my security message.
[You can safely assume that there’s also something that’s wrong with the message and the messenger, but I want to learn about the thing I likely can’t control or change – the supply of developers]
Here are some unfairly broad descriptions of stereotypes I’ve encountered along the way. The truth, as ever, is more nuanced, but I think if I can reach each of these target personas, I should have just about everyone covered.
Is there anyone I’ve missed?
I’m always happy to have one or more of these people in the room – the sort of developer who has some experience, and has been on a project that was attacked successfully at some point or another.
This kind of developer has likely quickly learned the lesson that even his own code is subject to attack, vulnerable and weak to the persistent probes of attackers. Perhaps his experience has also included examples of his own failures in more ordinary ways – mere bugs, with no particular security implications.
Usually, this will be an older developer, because experience is required – and his tales of terror, unrehearsed and true, can sometimes provide the “scared straight” lesson I try to deliver to my students.
This guy is usually a smart, younger individual. He may have had some previous nefarious activity, or simply researched security issues by attacking systems he owns.
But for my purposes, this guy can be too clever, because he distracts from my talk of ‘least privilege’ and ‘defence in depth’ with questions about race conditions, side-channel attacks, sub-millisecond time deltas across multi-second latency routes, and the like. IF those were the worst problems we see in this industry, I’d focus on them – but sadly, sites are still vulnerable to simple attacks, like my favourite – Reflected XSS in the Search field. [Simple exercise – watch a commercial break, and see how many of the sites advertised there have this vulnerability in them.]
But I like this guy for other reasons – he’s a possible future hire for my team, and a probable future assistant in finding, reporting and addressing vulnerabilities. Keeping this guy interested and engaged is key to making sure that he tells me about his findings, rather than sharing them with friends on the outside, or exploiting them himself.
Unbelievably to me, there are people who “done a project on it”, and therefore know all they want to about security. If what I was about to tell them was important, they’d have been told it by their professor at college, because their professor knew everything of any importance.
I personally wonder if this is going to be the kind of SDE who will join us for a short while, and not progress – because the impression they give to me is that they’ve finished learning right before their last final exam.
Related to the previous category is the developer who only does what it takes to get paid and to receive a good performance review.
I think this is the developer I should work the hardest to try and reach, because this attitude lies at the heart of every developer on their worst days at their desk. When the passion wanes, or the task is uninteresting, the desire to keep your job, continue to get paid, and progress through your career while satisfying your boss is the grinding cog that keeps you moving forward like a wind-up toy.
This is why it is important to keep searching to find ways of measuring code quality, and rewarding people who exhibit it – larger rewards for consistent prolonged improvement, smaller but more frequent rewards to keep the attention of the developer who makes a quick improvement to even a small piece of code.
Sadly, this guy is in my class because his boss told him he ought to attend. So I tell him at the end of my class that he needs to report back to his boss the security lesson that he learned – that all of his development-related goals should have the adverb “securely” appended to them. So “develop feature X” becomes “develop feature X securely”. If that is the one change I can make to this developer’s goals, I believe it will make a difference.
I’ve been doing this for long enough that I see the same faces in the crowd over and over again. I know I used to be a fanboy myself, and so I’m aware that sometimes this is because these folks learn something new each time. That’s why I like to deliver a different talk each time, even if it’s on the same subject as a previous lesson.
Or maybe they just didn’t get it all last time, and need to hear it again to get a deeper understanding. Either way, repeat visitors are definitely welcome – but I won’t get anywhere if that’s all I get in my audience.
Some developers do the development thing because they can’t NOT write code. If they were independently wealthy and could do whatever they want, they’d be behind a screen coding up some fun little app.
I like the ones with a calling to this job, because I believe I can give them enough passion in security to make it a part of their calling as well. [Yes, I feel I have a calling to do security – I want to save the world from bad code, and would do it if I was independently wealthy.]
Sadly, the hardest person to reach – harder even than the Salaryman – is the developer who matches the stereotypical perception of the developer mindset.
Convinced of his own superiority and cleverness, even if he doesn’t express it directly in such conceited terms, this person will see every suggested approach as beneath him, and every example of poor code as yet more proof of his own superiority.
“Sure, you’ve had problems with other developers making stupid security mistakes,” he’ll think to himself, “But I’m not that dumb. I’ve never written code that bad.”
I certainly hope you won’t ever write code as bad as the examples I give in my classes – those are errant samples of code written in haste, and which I wouldn’t include in my class if they didn’t clearly illustrate my point. But my point is that your colleagues – everyone around you – are going to write this bad a piece of code one day, and it is your job to find it. It is also their job to find it in the code you write, so either you had better be truly as good as you think you are, or you had better apply good security practices so they don’t find you at your worst coding moment.