Another technical book, this time because my employer lets me buy random technical books as long as I pinky swear to read them and this one sounded interesting and got good reviews.
First off, the book is a bit dated given its from 2011 — there are lots of references to Ubuntu 10.10 for example and they say to avoid Python 3, which has its historical charm. This is unfortunate given the first section of the book talks about setting up honeypots to collect malware to examine, but Dionaea for example had its last commit in 2021. I am left wondering if there are more modern honey pot systems that people use these days.
Secondly the book is definitely a cookbook and that’s on me for not noticing this about the book before buying it — its a series of recipes / scripts that do interesting things with malware. That said, it isn’t really teaching a cohesive set of skills, its more of a series of stepping stones along the path you might follow. I think that’s an unintended piece of important learning — books with “cookbook” or “recipes” in their title probably aren’t very good as an overview of a topic area. My bad.
That said, some parts of the book are very good — the discussion of whois, DNS, and Real Time Black Lists (RTBLs) is helpful and less focussed on providing scripts you could run. The discussion of how to log changes to a Windows system, detect attempts to hide files in NTFS filesystems, and detect changes to registry hives were interesting in an abstract way, but perhaps obvious to someone who actually uses Windows.
Overall, I’m a bit disappointed in this book and it will be exhiled to a shelf at the office as a punishment.
Malware Analyst's Cookbook and DVD
Michael Ligh, Steven Adair, Blake Hartstein, Matthew Richard,
Computers
John Wiley & Sons
November 2, 2010
747
A computer forensics "how-to" for fighting malicious code and analyzing incidents. With our ever-increasing reliance on computers comes an ever-growing risk of malware. Security professionals will find plenty of solutions in this book to the problems posed by viruses, Trojan horses, worms, spyware, rootkits, adware, and other invasive software. Written by well-known malware experts, this guide reveals solutions to numerous problems and includes a DVD of custom programs and tools that illustrate the concepts, enhancing your skills. Security professionals face a constant battle against malicious software; this practical manual will improve your analytical capabilities and provide dozens of valuable and innovative solutions Covers classifying malware, packing and unpacking, dynamic malware analysis, decoding and decrypting, rootkit detection, memory forensics, open source malware research, and much more.
I don’t think I’ve really reviewed a technical book here before, but I read the thing so I guess I should. This book is the certification guide for a “Cisco CyberOps Associate” certification, which is what they now call the CCNA Security qualification. Its a relatively junior certification, qualifying you to be a level one operator in a Security Operations Centre (SOC).
I read this book because I took a Cisco NetAcad course for the associated certification in the second half of 2022 (although it has continued to be a thing I plug away at in 2023). That was mainly motivated by a desire to more about a field that is clearly important, but hasn’t been core to my personal career.
This book is reasonably well written and readable — I’d read a chapter in the evening after work and its wasn’t a huge chore to churn though. I certainly learned things along the way, even if the certification seems to suffer from a desire to have everyone rote learn a lot of acronyms, which seems like a common ailment in the industry (AWS Certified Cloud Practitioner, I’m looking at you).
My main critism is of the qualification itself, which is that it is quite Cisco centric — almost all examples of the implementation of a technology are a Cisco product, which is great if you’re trying to demonstrate the depth of Cisco’s portfolio, but isn’t great if you’re competing with less vendor centric certification options. This is in contrast to the CCNA content, which feels more vendor neutral to me because its more fundamental.
That said, this book wasn’t a waste of my time and I learned stuff — which I guess is mission accomplished for a technical book?
Cisco Cyberops Associate Cbrops 200-201 Official Cert Guide
Omar Santos
Computers
Cisco Press
August 6, 2020
900
Modern organizations rely on Security Operations Center (SOC) teams to vigilantly watch security systems, rapidly detect breaches, and respond quickly and effectively. To succeed, SOCs desperately need more qualified cybersecurity professionals. Cisco's new Cisco Certified CyberOps Associate certification prepares candidates to begin a career working as associate-level cybersecurity analysts within SOCs.
There’s been a lot of talk recently about what we should include in OpenStack and what is out of scope. This is interesting, in that many of us used to believe that we should do ”everything”. I think what’s changed is that we’re learning that solving all the problems in the world is hard, and that we need to re-focus on our core products. In this post I want to talk through the various “layers” proposals that have been made in the last month or so. Layers don’t directly address what we should include in OpenStack or not, but they are a useful mechanism for trying to break up OpenStack into simpler to examine chunks, and I think that makes them useful in their own right.
I would address what I believe the scope of the OpenStack project should be, but I feel that it makes this post so long that no one will ever actually read it. Instead, I’ll cover that in a later post in this series. For now, let’s explore what people are proposing as a layering model for OpenStack.
What are layers?
Dean Troyer did a good job of describing a layers model for the OpenStack project on his blog quite a while ago. He proposed the following layers (this is a summary, you should really read his post):
layer 3: optional services — Horizon and Ceilometer
layer 4: turtles all the way up — Heat, Trove, Moniker / Designate, Marconi / Zaqar
Dean notes that Neutron would move to layer 1 when nova-network goes away and Neutron becomes required for all compute deployments. Dean’s post was also over a year ago, so it misses services like Barbican that have appeared since then. Services are only allowed to require services from lower numbered layers, but can use services from higher number layers as optional add ins. So Nova for example can use Neutron, but cannot require it until it moves into layer 1. Similarly, there have been proposals to add Ceilometer as a dependency to schedule instances in Nova, and if we were to do that then we would need to move Ceilometer down to layer 1 as well. (I think doing that would be a mistake by the way, and have argued against it during at least two summits).
Sean Dague re-ignited this discussion with his own blog post relatively recently. Sean proposes new names for most of the layers, but the intent remains the same — a compute-centric view of the services that are required to build a working OpenStack deployment. Sean and Dean’s layer definitions are otherwise strongly aligned, and Sean notes that the probability of seeing something deployed at a given installation reduces as the layer count increases — so for example Trove is way less commonly deployed than Nova, because the set of people who want a managed database as a service is smaller than the set of of people who just want to be able to boot instances.
Now, I’m not sure I agree with the compute centric nature of the two layers proposals mentioned so far. I see people installing just Swift to solve a storage problem, and I think that’s a completely valid use of OpenStack and should be supported as a first class citizen. On the other hand, resolving my concern with the layers model there is trivial — we just move Swift to layer 1.
What do layers give us?
Sean makes a good point about the complexity of OpenStack installs and how we scare away new users. I agree completely — we show people our architecture diagrams which are deliberately confusing, and then we wonder why they’re not impressed. I think we do it because we’re proud of the scope of the thing we’ve built, but I think our audiences walk away thinking that we don’t really know what problem we’re trying to solve. Do I really need to deploy Horizon to have working compute? No of course not, but our architecture diagrams don’t make that obvious. I gave a talk along these lines at pyconau, and I think as a community we need to be better at explaining to people what we’re trying to do, while remembering that not everyone is as excited about writing a whole heap of cloud infrastructure code as we are. This is also why the OpenStack miniconf at linux.conf.au 2015 has pivoted from being a generic OpenStack chatfest to being something more solidly focussed on issues of interest to deployers — we’re just not great at talking to our users and we need to reboot the conversation at community conferences until its something which meets their needs.
We intend this diagram to amaze and confuse our victims
Agreeing on a set of layers gives us a framework within which to describe OpenStack to our users. It lets us communicate the services we think are basic and always required, versus those which are icing on the cake. It also let’s us explain the dependency between projects better, and that helps deployers work out what order to deploy things in.
Do layers help us work out what OpenStack should focus on?
Sean’s blog post then pivots and starts talking about the size of the OpenStack ecosystem — or the “size of our tent” as he phrases it. While I agree that we need to shrink the number of projects we’re working on at the moment, I feel that the blog post is missing a logical link between the previous layers discussion and the tent size conundrum. It feels to me that Sean wanted to propose that OpenStack focus on a specific set of layers, but didn’t quite get there for whatever reason.
Next Monty Taylor had a go at furthering this conversation with his own blog post on the topic. Monty starts by making a very important point — he (like all involved) both want the OpenStack community to be as inclusive as possible. I want lots of interesting people at the design summits, even if they don’t work directly on projects that OpenStack ships. You can be a part of the OpenStack community without having our logo on your product.
A concrete example of including non-OpenStack projects in our wider community was visible at the Atlanta summit — I know for a fact that there were software engineers at the summit who work on Google Compute Engine. I know this because I used to work with them at Google when I was a SRE there. I have no problem with people working on competing products being at our summits, as long as they are there to contribute meaningfully in the sessions, and not just take from us. It needs to be a two way street. Another concrete example is Ceph. I think Ceph is cool, and I’m completely fine with people using it as part of their OpenStack deploy. What upsets me is when people conflate Ceph with OpenStack. They are different. They’re separate. And that is fine. Let’s just not confuse people by saying Ceph is part of the OpenStack project — it simply isn’t because it doesn’t fall under our governance model. Ceph is still a valued member of our community and more than welcome at our summits.
Do layers help us work our what to focus OpenStack on for now? I think they do. Should we simply say that we’re only going to work on a single layer? Absolutely not. What we’ve tried to do up until now is have OpenStack be a single big thing, what we call “the integrated release”. I think layers gives us a tool to find logical ways to break that thing up. Perhaps we need a smaller integrated release, but then continue with the other projects but on their own release cycles? Or perhaps they release at the same time, but we don’t block the release of a layer 1 service on the basis of release critical bugs in a layer 4 service?
Is there consensus on what sits in each layer?
Looking at the posts I can find on this topic so far, I’d have to say the answer is no. We’re close, but we’re not aligned yet. For example, one proposal has a tweak to the previously proposed layer model that adds Cinder, Designate and Neutron down into layer 1 (basic services). The author argues that this is because stateless cloud isn’t particularly useful to users of OpenStack. However, I think this is wrong to be honest. I can see that stateless cloud isn’t super useful by itself, but we are assuming that OpenStack is the only piece of infrastructure that a given organization has. Perhaps that’s true for the public cloud case, but the vast majority of OpenStack deployments at this point are private clouds. So, you’re an existing IT organization and you’re deploying OpenStack to increase the level of flexibility in compute resources. You don’t need to deploy Cinder or Designate to do that. Let’s take the storage case for a second — our hypothetical IT organization probably already has some form of storage — a SAN, or NFS appliances, or something like that. So stateful cloud is easy for them — they just have their instances mount resources from those existing storage pools like they would any other machine. Eventually they’ll decide that hand managing that is horrible and move to Cinder, but that’s probably later once they’ve gotten through the initial baby step of deploying Nova, Glance and Keystone.
The first step to using layers to decide what we should focus on is to decide what is in each layer. I think the conversation needs to revolve around that for now, because it we drift off into whether existing in a given layer means you’re voted off the OpenStack island, when we’ll never even come up with a set of agreed layers.
Let’s ignore tents for now
The size of the OpenStack “tent” is the metaphor being used at the moment for working out what to include in OpenStack. As I say above, I think we need to reach agreement on what is in each layer before we can move on to that very important conversation.
Conclusion
Given the focus of this post is the layers model, I want to stop introducing new concepts here for now. Instead let me summarize where I stand so far — I think the layers model is useful. I also think the layers should be an inverted pyramid — layer 1 should be as small as possible for example. This is because of the dependency model that the layers model proposes — it is important to keep the list of things that a layer 2 service must use as small and coherent as possible. Another reason to keep the lower layers as small as possible is because each layer represents the smallest possible increment of an OpenStack deployment that we think is reasonable. We believe it is currently reasonable to deploy Nova without Cinder or Neutron for example.
Most importantly of all, having those incremental stages of OpenStack deployment gives us a framework we have been missing in talking to our deployers and users. It makes OpenStack less confusing to outsiders, as it gives them bite sized morsels to consume one at a time.
So here are the layers as I see them for now:
layer 0: operating system, and Oslo
layer 1: basic services — Keystone, Glance, Nova, and Swift
layer 2: extended basics — Neutron, Cinder, and Ironic
layer 3: optional services — Horizon, and Ceilometer
layer 4: application services — Heat, Trove, Designate, and Zaqar
I am not saying that everything inside a single layer is required to be deployed simultaneously, but I do think its reasonable for Ceilometer to assume that Swift is installed and functioning. The big difference here between my view of layers and that of Dean, Sean and Monty is that I think that Swift is a layer 1 service — it provides basic functionality that may be assumed to exist by services above it in the model.
I believe that when projects come to the Technical Committee requesting incubation or integration, they should specify what layer they see their project sitting at, and the justification for a lower layer number should be harder than that for a higher layer. So for example, we should be reasonably willing to accept proposals at layer 4, whilst we should be super concerned about the implications of adding another project at layer 1.
In the next post in this series I’ll try to address the size of the OpenStack “tent”, and what projects we should be focussing on.
This is why I’m going to say no this time to the offer of a more public review, and I’ll do my best to take that on board next time when I know more about how long this sort of thing can take (I’m actually only about two days over schedule at the moment, but I really don’t want to slip any further).
Sorry Michael.
Anyways, I’m working on review comments for three chapters tonight, which is one of the things that made me think about this more. I’m really rather surprised about how positive the review comments have been so far given how I feel about the manuscript (I’ve always viewed myself as a bit of a perfectionist, and it’s always possible to improve something, so it’s really hard to turn the chapters in on time, because that means letting go).
I have independently decided that I want to include more in chapters three and four though, and the review team without my prompting suggested more content for chapter four, so it’s now a case of sitting down and making that happen. Well, back to work.
We intend this diagram to amaze and confuse our victims