Sep 01

Prose Just Got Real: The First Trilogy Has Working Titles!

By terranceacrow | News , Novel Pre-Production

My last post mentioned Larry Brooks’ Story Engineering (you can buy it here — I can’t recommend it enough!). The book’s a wealth of information about all aspects of writing a novel, from the nuances of character creation to plotting. The latter was of particular interest to me, since I had concluded that my writing skills lacked one critical part: I didn’t know how to plot a novel.

Yeah, I’m kinda disappointed with me, too. You’d think by now…

Putting aside my natural tendency to take myself to try myself, convict myself, and give myself a stern talking to, I’ve finished Story Engineering. I’m excited to say that after digesting the chapters about plot, and after applying the architectural principles Mr. Brooks described, I’ve come to a conclusion.

He’s right. There’s a repeatable way to approach plot. And I think I can do it.

That was the last obstacle to me starting my first trilogy. Well, to be completely honest, my first trilogy since high school. That means my excuses are exhausted.* It’s time to get started.

The trilogy’s working title is The Fall of Caerleon. I’m going to grapple with the idea of the purpose of power; of its uses, abuses, and controls; its links to our empirical and mystical aspects. The Conrad family, much like Masayoshi Son, has a long term plan to better humanity. Will that plan survive the enemies arrayed against it? Will it survive the Conrad family?

The first book, Divinity Falling, follows Melchizedek “Dek” Conrad as he struggles to push back the advances of Terran Consolidated Products and its hyper-cash reserves against his company. At the same time, his company is trying to get off world to gain the breathing room it needs to take the family’s plan to the next stage. Which force will be more compelling?

Olympia Dreaming, the second book, follows Jack Conrad’s fight against Aldertraum, one of Earth’s colonies, as it tries to take humanity on a dark but unfortunately familiar path. Can humanity rise above its hard-wired behaviors? Or is it doomed to remain in the cave forever? This takes place a couple of decades in Divinity Falling’s future.

The last book of this trilogy, Founders’ Rising, presents Benjamin Conrad and the maiden voyage of the Resolution. Set just after Olympia Dreaming, the story portrays the conflict between human power and its links to claims of divinity. Can human overcome their ancient tendencies, even in the face of species extinction? Will Aldertraum’s attacks prevail? Are they even the real enemy? Or is our own nature much more deadly?

The problem of human power has always fascinated me. We need power to get things done, to influence groups to come together to accomplish things that individuals can’t achieve. At the same time, our history’s littered with the aftermath of power gone mad. History’s also full of attempts to manage or control power. Most recently, we see the foundation of the United States and the establishment of three branches of government to act as checks on power. We’re witnessing a time when those checks have been attacked and eroded, but that just increases my interest: how can humanity harness its collective will without falling into demagoguery? How can we withstand the corrosive effects of hyper-cash — and should we? If we should, why? What’s the justification? I hope to explore those questions in this trilogy.

How do the titles sound to you? Any thoughts on humans and their exercise of power?

Now, please excuse me. I have some work to do!

* If you’re a writer, you’ll understanding to interpret this not as a statement of fact, but as a desparate plea!

Jul 29

One More Piece of the Puzzle…

By terranceacrow | News

One more piece of the puzzle and I’ll be ready to start working on the arcs for the first trilogy.

No, really! That’s the plan! This time for sure!

Why now? What’s changed since I wrote my last novels?* Well, my wife introduced me to Sterling & Stone. If you have any interest in self-publishing, go check out their site. Right now. I won’t mind! I’ll wait.

They’re busily perfecting the art of self-publishing high-quality works in a number of genres. Even better (as if that accomplish weren’t enough, which it is!), they share what they’ve learned. Watching their videos and listening to their podcasts is an investment that I have no doubt will pay off. I now have an idea of where to start when it comes time to publish the first book. That is to say, when I finish writing the first book.

I’ve reviewed my writing skills, and I found I have a gap. I know how to write sentences. My character development will improve over time. Thumbs up to my dialogue! But I don’t know how to weave a compelling story. I gave myself some homework: find a popular, self-published book on Amazon and figure out why it was popular. Here’s what I chose:

I could nit-pick the book — I hate similes, and I don’t think the writer, A. G. Riddle, ever met a simile he didn’t like. But you know what? I had a hard time putting it down. I was disappointed when it ended. Apparently, I’m not alone. Amazon says the trilogy (which includes The Atlantis Plague and The Atlantis World) has sold over 2 million copies.

Let that number — that astonishing accomplishment — sink in for a moment.

My homework was to figure out why that trilogy has sold 2 million copies — despite me not liking its similes.

I think I found the key in Larry Brooks’ book called Story Engineering:

He does an outstanding job of covering all aspects of writing novels, but his chapter on plot blew me away. He laid out, in clear and concise terms, what a successful plot should look like. He didn’t dictate an inflexible set of rules: he pointed out a clear set of guidelines that define what a successful novel’s plot should look like.

I think this is the last piece I need before starting the first trilogy.

How do I know that’s the last piece? I don’t. Not yet, at least. But I know this: I can’t tolerate any more excuses. My daughter’s out of college. I’m not getting younger (quite the contrary!). It’s time to put up or shut up; do or do not; spread my wings and fly; and <insert your favorite cliche here>.

As I work on the material, I’ll share bits and pieces here in the hopes you’ll see something interesting. Feel free to comment!

Now, time to get writing!


* Are you ready for this? I wrote my last novel over 30 years ago. 30 years! That’s like, a lot of time. It took me that long to exhaust my reservoir of excuses! It’s hard to believe that it’s been 30 years since Olympia orbited the planets of Sirius, or the Resolution was lost…

Jul 04

Wasn’t This an Application Security Blog?

By terranceacrow | News

Yes, it was!

Interstell, Inc.’s adjusting its properties to better serves its customers, so this site,, is transitioning to a blog covering the challenges and jobs of writing novels.

Realigning Our Sites2

The application security material is moving (and we hope expanding!) at this site:

Please visit us there!

And if you’re interested in writing novels, please check back here from time to time!


May 11

Where Does a Developer Even Start?

By terranceacrow | Security Industry

One Day, It Dawns on You…

IsDangerousMuchlyLet’s say you’ve developed code for awhile. If a Project Manager, business partner, boss, or someone else with requirements comes to you, you can convert their business-speak into technical requirements. You can turn those requirements into an application that gets the job done. Customers love the results of your labor! As the accolades roll in, you’re probably feeling pretty confident.

Then you read an article like this one in CSO Online that says 736 million data records were exposed in 2015. Troubled, you put your developers skills to work and look for a solid, technically-recognized reference to explain how your baby might be vulnerable. You find Verizon’s 2015 report called 2015 Data Breach Investigations Report. You read. And you read.

And you read.

You study the charts. You match your business’ profile against the ones in the report.

You set the report aside, realizing that it’s good high-level data, but you need something more concrete. You find the SANS Securing Web Application Technology (SWAT) Checklist. It has seven sections and a total of 58 individual entries. The picture’s getting clears; it’s good description, but few code examples, and some terminology may be unfamiliar.

Undaunted, you cast around for something more focused and helpful for you as a developer. You come upon the Open Web Application Security Project (OWASP)’s Top 10 Vulnerabilities. Finally! A resource designed specifically for developers! There are some actual code examples! But after more review, some of the examples are aging or refer to products that aren’t being updated. Or the examples aren’t in a language that you are using.

If the data’s there, it’s not in a form that’s easy to get ahold of.

nicelittleappyouhavethereSo, after hours of careful deliberation and research, you come to the conclusion:

Crap. I’m doomed.

If some of the biggest companies in the world can’t keep their data safe…

If even some nation-states can’t protect themselves…

If the leading industry solution providers don’t have something that’s easy to consume…
Yet your application still needs to run on the internet…

What can you do?

The Truth Is… Well, You Know!

It’s out there (the truth, that is).

You know why validating data’s important for your application, right? You wouldn’t let someone enter a negative dollar amount in a gambling game. You wouldn’t let someone enter “99/aa/0998af” as a birth date. You wouldn’t let someone upload an EXE file instead of a JPG. You wouldn’t do these things because you feel responsible for protecting the data that comes into your application, right? You know that the wrong data results in the wrong outputs. And that makes customers unhappy.

At its essence, that’s security.

The data’s out there. It’s just not packaged for quick consumption — which is what you as a developer need.

Coding Your Way to a Better Tomorrow

surebeatswithoutapparelIf you know how to code, you can make your applications more secure.

And how to we do that?

It’s cliche, but one module/class/servlet at a time.

In the coming months, I’m going to share what I’ve learned after decades of coding for various companies representing financial and other well-regulated industries. I’ll give you examples that you can copy and paste into your code — or that demonstrate the basic concepts so you rework the example according to your needs. I’ll cover both Java and PHP. I’ll release the example code under the BSD 2-Clause License, which should give you maximum flexibility and freedom.

In other words, I want to give you tools to help you secure your code so your customers are happier, your boss is happier, and you can sleep better at night knowing you’ve done your best to secure your code.

You’ll add security to your perspective without even thinking of it as security. You’ll be back to converting requirements to your usually amazing applications. Only this time, you’ll know how to avoid the weaknesses that landed many companies in Verizon’s report. Will your code be unassailable? Good heavens, no! But it will be better. And not only better at a specific point in time: you’ll understand how to keep it as secure as is reasonably possible over the long haul.

Watch for the curriculum outline and some sample training videos/articles in the coming months!

Apr 12

Talking with Security Doubters

By terranceacrow | Techniques

Surrounded by Doubt…

In my last post, I talked about a scenario designers and developers know all too well: well-meaning management, project managers, architects, and business staff who don’t believe security is important — or don’t believe it’s important enough to warrant your time. Many of these doubters have direct input into the amount of effort you can spend on a project. If you’re a developer who knows what can happen when you ignore customer’s demands for reasonable security, what can you do?

Put Down the Stones!

nostonesFirst, let me address a tendency we have as developers. You are burdened with knowledge of how to get things done.* If you’re security conscious, you understand what insecure code or coding practices can do to customer trust. We tend to get frustrated or angry when people try to override our coding experience with their own priorities.

Becoming angry, though, won’t help. At best, they’ll just ignore you and label you a prima donna. At worst, they’ll just call you a prima donna and put you on work improvement because you’res not being a team player (in their eyes). But if (justifiable) anger’s not the answer, what is?

A Better Approach

Back in 1997, a modern philosopher named Don Miguel Ruiz came up with The Four Agreements to guide how we interact with others and ourselves. I’ve found them to be an effective way to advocate for security on behalf of the customer. Those rules are:

  1. Be impeccable with your word: Don’t be over the top or hyperbolic. Clearly and honestly state the requirements as you see them to your manager or team leader.
  2. Don’t take anything personally: Chances are, the folks arguing with you are just trying to meet their obligations and go home for the day. Unless you’ve knifed them (or one of their loved ones), it’s unlikely they’re attacking you personally.
  3. Don’t make assumptions: As developers, we tend to have a precise vocabulary. To my astonishment, I’ve learned not everyone’s like that (how do they even get to work without such precision?). Don’t assume they’re an idiot for not agreeing with you. Also, don’t assume you’re right! Even security requirements are subject to input from budget and risk. Management may have heard your pleas, considered them against the application’s risk posture and/or budget, and decided they could afford the risk.
  4. Always do your best: Represent your profession in the best way you know how. Don’t consciously exclude a security requirement without at least making your team leader or immediate supervisor aware. You could do worse than having the reputation as that “developer who’s always worried about security!” If you’re always striving for your best, you can still move your skills forward — even in a security-poor environment.

SometimesCantWin2Unfortunately, that last point is important: Sometimes, despite your best efforts, despite your eloquence and tenacity, despite your well-reasoned arguments and appeals to customer satisfaction, the team may decide not to incorporate the necessary security controls. They might elect to allow unfiltered input under the reasoning that the code uses stored procedures, so it’s safe. They might not understand that the input might include cross-site scripting (XSS) attacks that could ensnare a browser displaying the data. After all, security is only as strong as its weakest link. What can you do then?

As I see it, you have two choices:

  1. Accept the decision and keep working: If you enjoy working with this team, accept the decision and keep working. Certainly, keep a log of your concerns (e.g., keep the e-mails you sent warning of the security vulnerability) in case someone tries to blame you later. But otherwise, keep studying security on your own so your skills don’t stagnate. Also, hope the team will take your advice the next time!
  2. Find another job, give your two-weeks’ notice, and move on: If you find that no one’s listening, if you see customer data being compromised (especially if that data personally identifies a customer or reveals their health care data), it might be time to move on. You don’t want to lose your edge by working the architects, designers, or developers who don’t understand security. Again, keep a log of your efforts to make the team aware so they don’t try to frame you, but graciously move on. And don’t burn the bridges behind you! You never know when you might need to make a strategic retreat!

The real shame is that writing secure code is not materially different from writing insecure code. In fact, I’d argue that it’s actually less expensive, since the resulting code requires less operational support and is less likely to embroil the company in an inadvertent data disclosure. Those things take a lot of time to manage and correct! And that’s not even counting potential legal fees as the US Federal Trade Commission begins to get involved.

Always advocate for doing the right thing. It sometimes doesn’t seem worth it, but you have to live with you, so you might as well act in a way you can respect!

In the next post, we’ll take a look at giving your security concerns a sound foundation.



* After all, we’re the ones who tell the program exactly what to do and when to do it. The business team has more knowledge of why things are happening, but when it comes to exactly what’s happening, we’re at the epicenter.

Mar 11

Security: Not Just for Banks Anymore!

By terranceacrow | Justification

Let’s say you’re a responsible corporate citizen. You want to retain customers and attract new customers. Maybe you architect applications, maybe you design them, or maybe you code them. If you’ve every brought some aspect of application security — say, you point out it’s a really good idea to disallow cross site scripting (XSS) — I bet you’ve run into opposition like:

  1. We’re not a bank! We don’t need all that security.
  2. We’re not a military installation. Why would we waste time and resources on security?
  3. We don’t have any sensitive information. Why are you trying to slow the development process down with useless security?
We're not a bank! Why do we need security? Answer: You don't -- if you don't care about customers!

We’re not a bank! Why do we need security? Answer: You don’t — if you don’t care about customers!

Those might have been legitimate questions sometime in the past. When, I don’t know, but I’m trying to be charitable here. The point is, those questions are invalid now. Why?

  1. Money isn’t the only thing malicious actors steal. Personal information, log-on information ( typically an e-mail address), or even just source IP addresses can be useful to them. In other words, if you have an application on the Internet, it’s of interest to malicious actors. How will your existing customers react if your site’s compromised? Will such an event help or hurt future potential customers?
  2. Sure, securing military installations is critical. But so is securing your installation! Ask doubters this question: if a malicious actor were loose on your servers, what havoc could they wreak? How would your customers react to receiving spam from your compromised servers? Would potential customers be more or less likely to consider you if they know your reputation through spamming?
  3. Your site may not store personally identifiable information. You might not store financial information. But you store something — or you wouldn’t have an application! How would an existing customer react if they find their data spewed all over the Internet — even if it’s just a record of which cat pictures they looked at? Would you join a website that allowed such shenanigans?
Would you use a site that you can't trust? Would your customers?

Would you use a site that you can’t trust? Would your customers?

It’s not even accurate to say security isn’t optional. It’s more accurate to say that security is a requirement, just as important as any other business or technical requirement. Not taking security into account means increasing the risk of losing existing customers and decreasing the chance of obtaining new customers.

People who ask questions like the ones above simply don’t understand what they’re asking. We’ll talk about how to deal with them in the next post.

Jan 07

Content Coming Soon

By terranceacrow | Uncategorized

In the coming weeks, please expect to see training modules to describe how to protect your application against real internet threats. I’ll focus on two environments: PHP and Java/Tomcat. However, the concepts will be universal.

Plus, instead of providing isolated chunks of code that might be hard to understand out of context, I’ll provide working demonstrations that you can download and work with.

I’ve developed more years than I care to count, and I’ve seen technology change a lot. But one idea has remained constant: as developers, we want to write code that delights the people who use it. I’m going to show you how to make your delightful code even more delightful by protecting your users’ data, keeping it safe, and keeping it available to them.