Whether we like it or not, the way we architect, utilize, and secure the networks and systems under our control has changed. When servers were safely tucked away behind corporate firewalls and perimeter-deployed intrusion prevention controls, organizations became complacent and dependent on their host security. Unfortunately, inadequately architected security controls that rely solely on broad network-based protection can make the migration of an organization’s systems to private, public, and hybrid cloud hosting even more exposed to attackers than they were before.
Everyone has heard the “defense in depth” analogy relating security to a medieval castle with controlled access to different locations of the castle and a defensive moat around the perimeter. This “hard outside” and “soft inside” model was designed to make it as difficult as possible to get past the perimeter. However, once inside the walls, the trusted individual had elevated access to resources within the network.
Unsurprisingly, the medieval defense analogy has lost much of its relevance in a world where systems and users move effortlessly from within the confines of a walled corporation, to a local coffee shop, and perhaps even to a different country as part of normal business operations.
Securing the next generation of hosting platforms requires a new approach that not every organization is ready for. Some industry analyst firms promote the idea of a “cloud first strategy” for all technology deployments. Though not a bad idea, per se, this doesn’t mean that forklifting your entire architecture into cloud or containerized environments should be your number one priority – especially if you’re being forced to choose between a new architecture and the traditional security controls that you depend upon.
Thankfully, technology has evolved to allow for more seamless security in environments that need to span traditional datacenters, virtualization, and cloud environments. This has allowed organizations to grow their capabilities without the need to choose between having security and having new technology stacks.
So how do we, as security professionals and business owners, decide what mitigating controls should be deployed to future-proof our security? It’s actually much easier than it sounds. To learn more about how to perform security beyond the perimeter please read my full post on https://www.juniper.net/us/en/dm/security-beyond-the-perimeter/.
I’ve had a lot of positive feedback from my first post which explained how to create the Trello board to track your Call For Paper (CFP) due dates, submissions, and results. In this post, I’ll explain how to create the cards and populate them with the required data to better manage your CFP pipeline.
To start your first card click the ‘Add a card…’ link in the CFP Open swim lane.
Within the card, place the location of the conference in the ‘Add a more detailed subscription…’ section and select the Save button. Note: I strongly advise that you follow a consistent location naming (e.g. Houston, TX or Houston, TX, USA) to make visualizing the data easier later on.
After the date is selected I fill the card with more CFP-specific information that I find from the event website, Twitter, or a third-party CFP site. I also pate the URL for the CFP submission form into the card so that I don’t have to hunt for it later (it automatically saves it as an attachment). If other information, such as important dates, conference details, or comments about the event are available I often add those in the ‘Add Comment’ section. Just make sure to his the ‘Save’ button or the data won’t be added to the card.
Optionally, you can leverage the ‘Labels’ button to assign color coded tags to denote different things. For example, I’ve used these to denote the audience type, the continent, country, state/province where the event is located, and whether or not travel and expenses (T&E) are covered. These are really just informational to help you prioritize events.
You now have your first conference CFP card that can be moved through the board calendar pipeline – something that I’ll discuss in my next blog post.
By Andrew Hay, Co-Founder and CTO, LEO Cyber Security.
I speak at a lot of conferences around the world. As a result, people often ask me how I manage the vast number of abstracts and security call for papers (CFPs) submissions. So I thought I’d create a blog post to explain my process. For lack of a better name, let’s call it the Hay CFP Management Method. It should be noted that this method could be applied to any number of things from blog posts to white papers and scholastic articles to news stories. I have successfully proven this methodology for both myself and my teams at OpenDNS, DataGravity, and LEO Cyber Security. Staying organized helped manage the deluge of events, submitted talks, and important due dates in addition to helping me keep track of where in the world my team was and what they were talking about.
I, like most people, started managing abstracts and submissions by relying on email searches and documents (both local and on Google Drive, Dropbox, etc.). Unfortunately, I didn’t find this scaled very well as I kept losing track of submitted vs. accepted/rejected talks and their corresponding dates. It certainly didn’t scale when it was applied to an entire team as opposed to a single individual.
Enter Trello, a popular (and freemium) web-based project management application that utilizes the Kanban methodology for organizing projects (boards), lists (task lists), and tasks (cards). In late September I start by creating a board for the upcoming year (let’s call this board the 2018 Conference CFP Calendar) and, if not already created, a board to track my abstracts in their development lifecycle (let’s call this board Talk Abstracts).
Within the Talk Abstracts board, I create several lists to act as swim lanes for my conference abstracts and other useful information. These lists are:
* Development: These are talks that are actively being developed and are not yet ready for prime time.
* Completed: These are talks that have finished development and are ready to be delivered at an upcoming event.
* Delivered: These are talks that have been delivered at least once.
* Misc: This list is where I keep my frequently requested form information such as my short bio (less than 50 characters), long bio (less than 1,500 characters), business mailing address (instead of browsing to your corporate website every time), and CISSP number (because who can remember that?).
* Retired: As a personal rule, I only use a particular talk for one calendar year. When I feel as though the talk is stale, boring, or stops being accepted, I move the card to this list. That’s not to say you can’t revive a talk or topic in the future as a “version 2.0”. This is why keeping the card around is valuable.
Within the 2018 Conference CFP Calendar board, I create several lists to act as swim lanes for my various CFPs. These lists are:
* CFP open: This is where I put all of the upcoming conference cards that I know about even if I do not yet know the exact details (such as location, CFP open/close, etc.).
* CFP closes in < 30 days: This is where I put the upcoming conference cards that have a confirmed closing date within the next 30 days. Note, it is very important to record details in the cards such as closing date, conference CFP mechanism (e.g. email vs. web form), and any related URLs for the event.
* Submitted: These are the conferences that I have submitted to and the associated cards. Note, I always provide a link to the abstract I submitted as a way to remind myself what I’m talking about.
* Accepted: These are the accepted talk cards. Note, I always put a copy of the email (or link to) acceptance notification to record any details that might be important down the road. I also make sure to change the date on the card to that of the speaking date and time slot to help keep me organized.
* Attending but not presenting: This is really a generic catch-all for events that I need to be at but may not be speaking at (e.g. booth duty, attending training, etc.). The card and associated dates help keep my dance card organized.
* Accepted but backed out: Sometimes life happens. This list contains cards of conference submissions that I had to back out of for one reason or another. I keep these cards in their own column to show me what was successfully accepted and might be a fit for next year in addition to the reason I had to back out (e.g. conflict, personal issue, alien abduction, etc.).
* Completed: This list is for completed talk cards. Again, I keep these to reference for next year’s board as it provides some ballpark dates for when the CFP opens, closes, as well as the venue and conference date.
* Rejected: They’re not all winners and not everybody gets every talk accepted. In my opinion, keeping track of your rejected talks is as (if not more) important as keeping track of your accepted talks. Not only does it allow you to see what didn’t work for that particular event, but it also allows you to record reviewer feedback on the submission and maybe submit a different style or type of abstract in the future.
* Not doing 2018: This is the list where I put conference cards that I’ve missed the deadline on (hey, it happens), cannot submit to because of a conflict, or simply choose to not submit a talk to.
It should be noted that I keep the above lists in the same order every year to help minimize my development time against the Trello API for my visualization dashboard (which I will explain in a future blog post). This might sound like a lot of work but once you’ve set this board up you can reuse it every year. In fact, it’s much easier to copy last year’s board than starting fresh every year, as it brings the cards and details over. Then all you need to do is update the old cards with the new venue, dates, and URLs.
Now that we have our board structure created we need to start populating the lists with the cards – which I’ll explain in the next blog post. In addition to the card blog post, I’ll explain two other components of the process in subsequent posts. For reference, here are the upcoming blog posts that will build on this one:
* Individual cards and their structure
* Moving cards through the pipeline
* Visualizing your board (and why it helps)